I am using this software called Simple Agent Pro, and it primarily uses TCL code. I was wondering anybody familiar with TCL or Sapro would be kind enough to tell me how to import the modules into the .tel file for Sapro.
When I try this:
package require tclOO.h
The program stops working.
Any help would be appreciated.
I don't know Simple Agent Pro at all, but if you're doing a “guerilla install” of TclOO then you need a few things:
Make sure you're using Tcl 8.5 (see what package require Tcl returns).
If you're using 8.4 (note: 8.4 EOLed this month), TclOO will not work at all (and it cannot be backported).
If you're using 8.6, it already provides the TclOO package and you shouldn't need to fuss around with all this.
Do a build of TclOO and install it to a location you prefer.
This will require Tcl's internal source files; TclOO explicitly pokes its nose into places where most code shouldn't.
You probably don't need to have a custom build of 8.5; just the configured sources somewhere will do. (You might need to hack the configure scripts a little bit.)
Add the location that you installed TclOO to to the search path inside your Tcl 8.5 program.
lappend auto_path /the_dir/you_put/it_in
If you're using Windows, it's probably easiest to use forward slashes for this path anyway (this is a directory name that is always highly protected before it hits the OS, so that's OK).
Now you should be able to require/use the package.
package require TclOO
oo::class create Foo {
# etc.
}
Note that the case and exactly how you write it matters. The version you get ought to be at least 1.0 (earlier versions were for development only) which corresponds exactly with the API as supported in Tcl 8.6 (modulo a few things that require 8.6 for other reasons, such as being able to yield inside a method which only works in 8.6 because that's where yield was first defined).
You probably mean
package require TclOO
Case and other stuff is important there.
Next time you should also include the stack trace. If the program stops working, it should display that either as dialog or on stdout.
Related
I am working on an old internal project. I am working on windows. The puredata I am using is on 32bit.
There are some objects like [mtx_*~] [mtx_:] [mtx_.^] [mtx_circular_harmonics] have "couldn't create" error.
I have iemmatrix installed through "find external".
I tried older versions of Puredata extended or several versions of vanilla. I can't create mtx_, either.
From pd/externals/iemmatrix, I can find a file called "mtx_0x2a0x7e.dll", which I think is "mtx_~" after decoding.
There is not much information on the internet about it anymore.
The "official" version (not the one with the 'extended' suffix) is compiled as a multi-object library. So you have to load the library first, either with a command line flag '-lib iemmatrix' or with a [declare -lib iemmatrix] object in your patch (The latter is much preferred as it makes your patch more portable). When loaded, iemmatrix prints a greeter to the Pd console window:
iemmatrix 0.3.2
objects for manipulating 2d-matrices
(c) 2001-2015 iem
IOhannes m zmölnig
Thomas Musil
Franz Zotter
compiled Sep 6 2019 : 12:07:54
After that you can create objects like [mtx_*~]
The version 'v0.0-extended' was added to facilitate the migration away from now retired Pd-extended. Since it is compiled as a one-object-per-file library and many of the those objects have names that cannot easily be used in filenames, Pd-extended used a trick with an additional hexloader library that translates hex encoded filenames to the actual name of the objects. For being able to load objects from the extended version, you would have to install and load 'hexloader' first.
Having said that, it is highly recommended to use the official version which is actively maintained while the extended version is not and is there for historical reasons.
I've already Google'd for an answer, since this is a common problem, but all the replies point in using alternatives instead of explaining why this doesn't work, so I'm asking here.
I put this code in my Atom's init.coffee script:
beautify = require('js-beautify').html
But Atom fails with Failed to load init.coffee and Cannot find module 'js-beautify'. Curiously enough, this works on a package and this works if I type the exact same code on Atom's console.
Of course, I could write a package for this, in fact there are a couple available, this is just an example because I want to learn how to require modules from init.coffee for future tweaks.
Thanks a lot!
When you require() from init.coffee, Atom looks for those modules in its own path. An example of where you might want to do that is if you had oni = require('oniguruma') to get access to regular expression functions.
In order to get to js-beautify, you have to specify its complete path. So far, only explicitly declaring the entire absolute path has worked for me:
beaut = require 'C:\\Users\\<username>\\.atom\\packages\\atom-beautify\\node_modules\\js-beautify'
console.log beaut
In practice, the most reliable way to use a module like this is to globally install it so that you can link to your global NPM folder. Linking to a module inside a package will break if the package is ever uninstalled.
I have a question related to V4L-DVB drivers. Following the
Building/Compiling the Latest V4L-DVB Source Code link, there are 3 ways to
compile. I am curious about the last approach (More "Manually
Intensive" Approach). It allows me to choose the components that I
wish to build and install using the "make menuconfig". Some of these components (i.e. "CONFIG_MEDIA_ATTACH") are used in pre-processor directives that define a function in one shape if defined, and a function in another if not defined (i.e.
dvb_attach, dvb_detach) in the resulting modules (i.e. dvb_core.ko)
that will be loaded by most of the DVB drivers. What happens if there are two
drivers (*.ko modules) on the same host machine, one that needs dvb_core.ko with
CONFIG_MEDIA_ATTACH defined and another that needs dvb_core.ko with
CONFIG_MEDIA_ATTACH undefined, is there a clean way to handle this?
What is also not clear to me is: Since the V4L compilation environment seems very customizable (by setting the .config file), if I develop a driver using V4L-DVB structures, there is a big chance that it has conflicts with other drivers since each driver has its own custom settings. Is my understanding correct?
Thanks!
Dave
I'm getting ready to try to deploy some code to multiple machines. As far as I know, using a Makefile.pm to track dependencies is the best way to ensure they are installed everywhere. The problem I have is I'm not sure our Makefile.pm has been updated as this application has passed through a few different developers.
Is there any way to automatically parse through either my source or a few full runs of my program to determine exactly what versions of what modules my application is depending on? On top of that, is there any way to filter it based on CPAN packages? (So that I only depend on Moose instead of every single module that comes with Moose.)
A third related question is, if you depend on a version of a module that is not the latest, what is the best way to have someone else install it? Should I start including entire localized Perl installations with my application?
Just to be clear - you can not generically get a list of modules that the app depends on by code analysis alone. E.g. if your apps does eval { require $module; $module->import() }, where $module is passed via command line, then this can ONLY be detected by actually running the specific command line version with ALL the module values.
If you do wish to do this, you can figure out every module used by a combination of runs via:
Devel::Cover. Coverage reports would list 100% of modules used. But you don't get version #s.
Print %INC at every single possible exit point in the code as slu's answer said. This should probably be done in END{} block as well as __DIE__ handler to cover all possible exit points, and even then may be not fully 100% covering in generic case if somewhere within the program your __DIE__ handler gets overwritten.
Devel::Modlist (also mentioned by slu's answer) - the downside compared to Devel::Cover is that it does NOT seem to be able to aggregate a database across multiple sample runs like Devel::Cover does. On the plus side, it's purpose-built, so has a lot of very useful options (CPAN paths, versions).
Please note that the other module (Module::ScanDeps) does NOT seem to allow you to do runtime analysis based on arbitrary command line arguments (e.g. it seems at first glance to only allow you to execute the program with no arguments) and if that's true, is inferior to all the above 3 methods for any code that may possibly load modules dynamically.
Module::ScanDeps - Recursively scan Perl code for dependencies
Does both static and runtime scanning. Just modules, I don't know of any exact way of verifying what versions from what distributions. You could get old packages from BackPan, or just package your entire chain of local dependencies up with PAR.
You could look at %INC, see http://www.perlmonks.org/?node_id=681911 which also mentions Devel::Modlist
I would definitely use Devel::TraceUse, which also shows a tree of the modules, so it's easy to guess where they are being loaded.
Summary :
I have a project using GNU Autotools. I have a pot file. I need to update it. Is there a magical "make" task that run xgettext for me (I'm lazy ?)
Verbose version :
Hi
I am trying to setup a project using GNU autotools and gettext.
I'm trying to follow the 'lazy' path (that is, only writing configure.ac, Makefile.am, and such, and let tools generate the rest for me as much as possible).
I used gettextize once on my package, so I got a package.pot file created, and I derived a fr.po file (I'm trying to translate in french).
I never managed to get my code translated, but I figured out it might be because the code was not in the proper place. The translated string is in a lib instead of a main, and the documentation is quite unclear about what I must do in this case. If my main call a function in a lib, and the function from the lib is using _(). Should I use gettext of dgettext in this case ? My lib is just here for organisation purpose, so I'm okay with using the same domain (only one package.pot file for the whole app).
So, to try something simpler, I moved my string to the main (it's really just a hello world, for the moment). So I need to update the package.pot file, at least, to realize that the string position changed, need I ? In this case, would I use xgettext manually (painfully passing it the list of all interesting cpp files, which will be a pain in the ass when I have more than one file), or is there a 'make whatever' task somewhere that I can run ?
This may look stupid, but I've not been able to find it.
Also, any help on finding why my code is not translated, (anything not in http://www.gnu.org/software/gettext/FAQ.html#integrating_noop) is welcome !
Thanks
PH
Ok, it turns out that :
there is a update-po task in the generated Makefile of the po/ folder, that does just what I want ;
this tasks looks to file referenced in the POTFILES.in file, which I had forgotten to update.
So it was something stupid.