I'm trying to program a client for multitouch gestures using TUIO under SmallTalk/Visualworks.
In order to get the mcz package for TUIO, I'm using Monticello.
The problem is that whenever i try to load a package with Monticello, i always end receiving this error message :
I can show you the Stack if anyone is inerested in it.
Thank's in advance.
A mcz package is essentially a compressed zip file. The current implementation of Monticello in VisualWorks uses external shell programs to uncompress and compress the source code to a Monticello mcz file.
When porting packages from Monticello to VisualWorks under Windows, there is usually a problem finding the corresponding zip.exe/unzip.exe. To solve your problem, try to set your PATH variable to your zip.exe/unzip.exe.
Another approach is to download the Info-ZIP package from the web. Place it into a subfolder in the image directory and change the execution logic of the VisualWorks Monticello Package. Browse for senders of shOne: in the VisualWorks Monticello Package and change the call.
The next thing to keep in mind when porting packages from Squeak or Pharo is to always define a Namespace which is named extactly after the first word of the monticello package name (upTo: $-). Define the namespace before loading the package.
i.e. JQueryMobile-Libraries-NickAger.10.mcz -> Define a Namespace JQueryMobile
Don't forget to import necessary Namespaces that the imported code requires to resolve the superclass names.
i.e. JQueryMobile needs Seaside.*, Javascript.*, JQuery.*, Grease.*, Smalltalk.*
Related
I am new to WebRTC stuff. I cloned the webrtc_ios main branch, and I built the framework as instructed here with the python script for arm64. When I add this to my Xcode project as a framework, everything is fine. Project builds, I can import files using <WebRTC/...> syntax.
However, I need to use RTCMTLRendeder.h file. Building a framework with python script leaves some of the header files out. (When I take a look at WebRTC.h inside the built framework, I can see that this file is missing) How can I include all header files that actually exist inside /webrtc_ios/src/sdk/objc/components folder while building the framework? I can see RTCMTLRenderer.h and .mm files are in that folder before using the build script. When turned into a framework those files don't exist inside the framework anymore. Why? And is there any other way to actually copy those files into the project as well?
Turns out you need to create your own, long renderer class which does not inherit from RTCMTLRenderer at all if you want to render on Metal view manually in a Swift/ObjC hybrid project (at least this is how I solved it). That class does whatever RTCMTLRenderer does, and grabs pixel buffers from RTCVideoTrack through an RTCVideoView.
I'd like to be able to view and make changes to the source code of installed (via zef) perl6 modules. How can I do that?
On my system, the module sources are under ~/.perl6/sources/ and there's also some kind of metadata file about the modules in ~/.perl6/dist/.
I can also use zef locate ... to show a module's source path, but making changes directly to the source files doesn't seem to have any effects (i.e., use the module from the REPL doesn't show my changes).
I'm guessing it's because the modules were pre-compiled, and perl6 doesn't pick up my changes and re-precompile the modules when I make changes directly to the module source files that way...
UPDATE: Deleting the corresponding pre-compiled files under ~/.perl6/precomp/... seems to work, but I'm not sure how and if that messes up anything.
I'd like to be able to view and make changes to the source code of installed (via zef) perl6 modules. How can I do that?
Please, don't do it that way. Installed modules are supposed to be immutable and as you've found out: if there is a pre-compiled version of a module available, it will not check if the original source file has been updated. That's because it doesn't have to, because it is considered immutable.
If you want to test changes on an installed module, please download the tar file / git clone the module's distribution, make changes you need in there, and then do:
zef install . --force-install
while in the top directory in the distribution. That will re-install the module and handle pre-compilation for you.
I created a small vue.js library that is using scss for styling and published that as npm package. It works well with a default theme included into the package. But what if I would like to provide a custom theme from the application that consumes that npm package, how would you do that?
The source for a very basic version of the library is here: https://github.com/gwildu/gwi-vue-components
The idea is, that you would copy paste the styling folder somewhere (e.g., into your application directory or into another npm package) and configure the library package to import from that copyied directory.
I did some investigation myself and found that there is a big discussion about having dynamic imports in sass since years. This issue (open since 2013) claims to add such a feature (they call it load). Not sure, how actively sass is still developed and when this feature will be supported. For now I see 3 possible solutions:
move to LESS as it supports dynamic imports. Semantic UI gives you a hint about how theming could be done in LESS
It is possible to import from relative paths in SASS. That way you are also able to import from a parent directory of your package root directory (your application directory) like, e.g., #import '../../theme/index';. You would support somewhere in your package an example of a theme that the consumer then would have to copy to, e.g., the root directory of his application and adjust it to his needs. In your package you would then import the theme from that directory in the consumers application folder. The downside is, that the package would not work out of the box
You have a default theme in your package and you add some instructions into the readme how the user can override that theme in a build script. The consumer would have to copy the default theme to his application directory, adjust it to his needs and in the build script he would replace the theme in, e.g., node_modules/your-library-package-folder/theme/ by the theme in your application folder.
To be complete here is the approach with a dynamic import (that is not yet supported by SASS):
In your main theme file in the library package (that would be imported by the components) you would do a relative import of kind of a config file from the consumers application folder like in approach 2 (see above) but that config file yould not contain the theme but only the import path of the theme in a variable. that variable then would be used by the package main theme file to import the theme. For making the library work out of the box, I guess there would be a way to have a default theme as backup if the config file in the consumers directory would not exist (not tested)
Update:
I tried approach 3 but failed to get something useful. The issue with that approach is that you would have to somehow sync your custome theme with the default theme when you update the library to a higher version which might get too complex to handle in a reasonable way. Then I tried to use the overwrite feature of SASS as described here: How to overwrite SCSS variables when compiling to CSS which led me to approach
In your library component you first import a file with possible custom variables and you declare your variables in the library as default.
The issue with that approach is that SASS does not support optional imports. The file with the custom variables have to exist somewhere. So if the library updates you again have to sync your custom theme files for each component / file that was changed in the library. Apparently SASS also don't want to support such a feature in the future: https://github.com/sass/sass/issues/779 which is sad, as it seems to me an essential feature for being able to do theming without a highly complex build step.
Overall, it seems SASS itself is making every effort to prevent a simple theming approach which makes me think of moving back to LESS again. Not having a simple way for static theming in SASS in my opinion outweight the cons of not having an easy way to define custom functions in LESS.
I am installing a package manually on my own system because I need to make some changes to it that aren't available in the basic version in my package manager. I also am trying to keep packages installed locally if possible, so I'm installing it with prefix=$HOME/.local instead of the more common prefix=/usr/local.
When I do this, I have no problem executing the program from my terminal, because I added ~/.local/bin to my PATH and the package was installed with relative paths to its shared libraries (i.e. ~/.local/lib/<package>). Executing from the command line is no problem, but I want to be able to access it from the favorites menu in gnome, and for that I need to make use of the <package>.desktop file.
I could hard-code the path to the executable in the .desktop file itself, but when I pull a later version down and re-install it, I'll have to redo those steps. I was wondering if there's a way to avoid that.
I've tried symlinking the executable to a directory where .desktop files do have included in their path, and the application is correctly treated as a GUI option, but launching the executable results in an error trying to find a shared library. I think this has to do with how cmake handles rpaths, which to my understanding is a way of relatively linking executables with their required libraries.
I think what I want to do is have PATH inside a .desktop file include ~/.local/bin, without changing the .desktop file itself. Can I alter the 'default' path used in accessing a .desktop file?
The answer to my question was found in the Archwiki:
Specifically, I needed to add ~/.local/bin to my path in ~/.xinitrc. Now my graphical programs work as expected.
I have a python script which is processing XML using xml.dom.minidom.
When I executed it with Jython by command line (jython myfile.py), everything was fine.
But when I tried to do the same thing embedding it into a java application, (I mean reading it as an java string then passing this string for evaluation) I got:
import xml.dom.minidom
ImportError: No module named xml
Which is driving me crazy. I tried to use different jython version (2.2, 2.5), to clear the cache, but nothing works!
Jython's Documentation tells me that we can use this module without any particular remarks.
Some people had the same problem on the internet but never got any replies. Except this:
here but still nothing work. I think I have the correct values in my jython registry, because it's working using the command line! It's just the embedding which fails everything.
I'm using a full install of Jython.
Why so much trouble, so?
Thanks in advance.
i've never done this before, but are you trying to embed jython like they did here or here? do you know where you got the jython.jar in your java classpath from? if you know where your jython module is located on disc then you might be able to just add that path as they did at the bottom of this page. To find the location of your module, load up jython and look in sys.path for a path that ends in Lib. that location should have a directory named xml (the xml package) which contains a directory named dom (the dom package), which contains a file minidom.py (the minidom module).
The xml module (jython) isn't on the the python-path of your embedded jython.
This may help:
use a jython-jar which contains the Lib (and all the Batteries :-)
put the Libs on the classpath of your java app
to help debug:
log "sys.path" in your embedded jython