From joerg at alea.gnuu.de Sat Dec 4 07:26:33 2004 From: joerg at alea.gnuu.de (Joerg Sommer) Date: Tue Jan 30 08:52:03 2007 Subject: [slang-users] slang2: Bug in integer()/hex_atoul() Message-ID: Hi, I found a bug in integer(): #v+ $ xjed-2.0 -batch -l ~/slang-bug.sl loading /home/joerg/programmieren/jed-B0.99-17.56/lib/site.slgned on a short wor loading /home/joerg/programmieren/jed-B0.99-17.56/lib/os.sl loading /home/joerg/programmieren/jed-B0.99-17.56/lib/menus.sla short integer. loading /etc/jed.conf loading /etc/jed-init.d/00debian.sl format above. A value of -1 or -2 means the loading /etc/jed-init.d/05home-lib.slt->string_offsets + 2 * offset); loading /etc/jed-init.d/55ispell.slt->numbers + 2 * offset); loading /home/joerg/programmieren/jed-B0.99-17.56/lib/sl_utils.sl loading /var/cache/dictionaries-common/jed-ispell-dicts.sl loading /home/joerg/.jed/jed.rcnteger (*(int **) ptr); loading /home/joerg/programmieren/jed-B0.99-17.56/lib/colors/black3.sl loading /home/joerg/programmieren/jed-B0.99-17.56/lib/keydefs.sl loading /home/joerg/programmieren/jed-B0.99-17.56/lib/compress.sl loading /home/joerg/slang-bug.sl xx:4 xx: $ cat ~/slang-bug.sl define bla() { variable foo="xx:"; try { foo += string( integer( () ) +4 ); } catch ParseError; message(foo); } bla("hoelder"); bla("xhoelder"); #v- The problem is in hex_atoul() because the tailing h is used for something - I don't know what. But it isn't checked if there are any numbers before 'h' (or u or l). So integer("h") == 0. Joerg. -- Der Kl?gere gibt so lange nach bis er der Dumme ist. From davis at space.mit.edu Sat Dec 4 13:43:52 2004 From: davis at space.mit.edu (John E. Davis) Date: Tue Jan 30 08:52:03 2007 Subject: [slang-users] slang2: Bug in integer()/hex_atoul() In-Reply-To: References: Message-ID: <200412041843.iB4IhqDj021722@aluche.mit.edu> Joerg Sommer wrote: >The problem is in hex_atoul() because the tailing h is used for something >- I don't know what. But it isn't checked if there are any numbers before >'h' (or u or l). So integer("h") == 0. Thanks for reporting this. Ditto for "L" and "LL". The "h" suffix may be used to defined a short integer: typeof (1h) ==> Short_Type typeof (1L) ==> Long_Type typeof (1LL) ==> LLong_Type I may release a new snapshot _next_ weekend. I would like to revisit the issues associated with namespaces that were discussed here previously. Hopefully next weekend's release will address those issues. Thanks, --John From davis at space.mit.edu Sun Dec 12 13:31:14 2004 From: davis at space.mit.edu (John E. Davis) Date: Tue Jan 30 08:52:04 2007 Subject: [slang-users] slang2 pre-release snapshot 3 available Message-ID: <200412121831.iBCIVEIP009567@aluche.mit.edu> Hi, As promised a new development snapshot of slang2 is available: ftp://space.mit.edu/pub/davis/slang/2.0-devel/slang-pre2-r3.tar.gz This version includes a few minor bug-fixes as well as a new facility for constructing debugging tools and profilers. As an example of its use, slsh contains a file called "stkcheck.sl" that defines a couple of functions: enable_stack_check and disable_stack_check. The idea is that if you suspect that a portion of your slang code is leaving something on the slang run-time stack, then put, e.g., require ("stkcheck.sl"); % alternatively use ()=evalfile("stkcheck.sl"); enable_stack_check (); at the top of the file containing the suspect code. (In order for "stkcheck.sl" to be picked up, it must be on your load-path.) Then run the code. A line with an unchecked return value such as fprintf (stdout, "foo\n"); should be flagged by the stack checker. If portions of your code contain functions that play games with the stack, e.g., % Put a couple of values on the stack 1; 2; args = __pop_args (2); . . then to avoid such lines being caught by the stack checker, turn off stack-checking for the compilation of the function via disable_stack_check, e.g., enable_stack_check (); . . disable_stack_check (); define play_stack_games () { . . } enable_stack_check (); . . Note: When running with jed in interactive mode (not batch), the stack-check messages will be written to the *traceback* buffer. Otherwise the output will go to stderr. The first cut at a profiler is included in the examples directory. My development efforts for the next release will be focused on the namespace issues that were previously discussed as well as the migration to libtool. Changes since 2.0.0 pre-release 2 1. autoconf/aclocal.m4: "if [...]" replaced by "if test ..." (Lloyd Zusman) 2. src/slsearch.c: BM searches for a string with the same length as the string to be searched was failing. 3. slsh/scripts/jpegsize: New demo script that finds the dimensions of jpeg-encoded images. 4. src/slstd.c: Added _slang_install_prefix intrinsic variable. 5. src/slboseos.c: New file. This file allows to define callback functions that will be called at the beginning (BOS) and end (EOS) of every statement executed by the interpreter. 6. slsh/lib/stkcheck,sl: The code in this file makes use of the new BOS/EOS hooks to display lines in a source file that leave something on the slang stack. 7. examples/profile.sl: This file defines a few functions that take advantage of the BOS/EOS hooks to profile slang code. 8. src/slarrfun.inc: sum and cumsum tweaked to use a "compensated summation" technique to reduce the effect of roundoff and truncation errors. 9. src/slmisc.c: SLatoi("h") was producing 0, and not an exception. 10. src/slmath.c: On VMS, slang is compiled with IEEE support (Jouk Jansen). From mnoble at space.mit.edu Sat Dec 18 11:27:28 2004 From: mnoble at space.mit.edu (Michael Noble) Date: Tue Jan 30 08:52:04 2007 Subject: [slang-users] slang2 pre-release snapshot 3 available In-Reply-To: <200412121831.iBCIVEIP009567@aluche.mit.edu> References: <200412121831.iBCIVEIP009567@aluche.mit.edu> Message-ID: <200412181627.iBIGRSGw015152@svoboda.mit.edu> > This version includes a few minor bug-fixes as well as a new facility > for constructing debugging tools and profilers. As an example of its > use, slsh contains a file called "stkcheck.sl" that defines a couple > of functions: enable_stack_check and disable_stack_check. FYI: Within the impending release I've added code to the SLgtk examples launcher to conditionally exercise this new stack checking feature: #ifeval _slang_version >= 20000 require("stkcheck"); enable_stack_check (); #endif Running "slgtk-demo --auto" (which exercises some 4500 lines of S-Lang code sprinkled throughout 40+ guilets) reveals no problems, either in the stack check implementation or SLgtk. Regards, Mike From mnoble at space.mit.edu Wed Dec 22 10:24:45 2004 From: mnoble at space.mit.edu (Michael Noble) Date: Tue Jan 30 08:52:04 2007 Subject: [slang-users] SLIRP 1.5 released Message-ID: <20041222152445.GA31228@svoboda.mit.edu> I am pleased to announce that SLIRP version 1.5 is now available at http://space.mit.edu/CXC/software/slang/modules/slirp/ SLIRP is a C code generator, aimed at simplifying the process of creating modules for the S-Lang scripting language. Using it can dramatically reduce the time and effort required to make a wide range of C, C++, and FORTRAN codes callable directly from the S-Lang interpreter. This release is by far the most significant to date, the highlights of which are given below. Regards, Mike Noble ---------------------------------------------------------------------------- Changes in v1.5.0 (12/19/04) 1) Support function annotations, which provide powerful and flexible means of customizing the generated code. For example, a C function prototyped as having M inputs and N outputs may be called from S-Lang as though it were a function of M' inputs and N' outputs. 2) This is achieved by customizing the bundled slsh with the S-Lang preprocessor extension module (see ./preproc), and using it to add #argmap, #funcmap, #prototype, #retmap, #ignore, etc directives. 3) Add initial support for C++, which includes: . wrapping of overloaded functions and those with default values, but not templates or operators . generation of pure/standalone C wrappers from C++ code (i.e., containing no S-Lang C api calls) via new -cfront option Sample usage given in new ./examples/cpp directory. 4) Initial support for SLang 2 5) Macros may now be wrapped as if they were fully prototyped functions, via slirp_map_macro(). 6) Moved toggle_error_hook() function to new standalone test framework package [ TESS, the (Te)st (S)ystem for (S)-Lang] 7) Added default type mapping for void* and 'unsigned long int' types. 8) The distinction between arguments explicitly declared as arrays (e.g. float f[]) and those ambiguosly declared as arrays or refs (e.g. float *f) has been deprecated. Thus slirp_map_array() has also been deprecated. 9) Address bugs seen while parsing rather complex glibc headers (submitted by Paul Boekholt, paul@boekholt.com) 10) Perform macro substitutions upon args within function prototypes. 11) SLIRP now automatically maps all unknown types (be they function return values OR args within function parameter lists) to the opaquely-typed void_ptr. The new -noautotype option turns this off. 12) Prevent simultaneous loading of incompatible SLIRP-based modules, by introducing an ABI version # which will be checked at load time. 13) Sharpen the saw (resulting in better performance and smaller modules) . emit fewer, at times many, lines of code . perform only a single pass over input files . code is now emitted to a single file . obviating the -d switch, which has been eliminated . except for module init func, all generated funcs are now static . remove support for deprecated -consts, -init, and -opaques switches . better recognition of function pointer and enum args . exhibit use of new #ignore directive (2) in OpenGL and MySQL examples . strip "int" return types from C wrappers for FORTRAN subroutines (dburke@cfa.harvard.edu) From mnoble at space.mit.edu Wed Dec 22 15:02:38 2004 From: mnoble at space.mit.edu (Michael Noble) Date: Tue Jan 30 08:52:04 2007 Subject: [slang-users] SLgtk v0.5.11 released Message-ID: <20041222200238.GA1478@svoboda.mit.edu> Announcement ============ Version 0.5.11 of SLgtk is now available at http://space.mit.edu/CXC/software/slang/modules/slgtk This version is motivated primarily for compatibility with version 1.5 of the SLIRP code generator (with which SLgtk is built). Highlights of both releases are given below. Description =========== The SLgtk package binds the Gtk2 and GtkExtra widget sets to the S-Lang scripting language (www.s-lang.org). SLgtk wraps more than 2200 functions from Gtk2 and its constituent libraries, includes over 4500 lines of sample code in 40+ working guilets. The distribution also bundles a code generator (SLIRP) which can be useful for building additional S-Lang modules from C, C++, or FORTRAN, as well as straight C wrappers for C++. SLgtk also includes a visual version of the powerful S-Lang "where" command, extensions to and performance enhancements for several GtkExtra widgets, and a pixbuf loader for the FITS image file format widely used within astronomy. Regards, -Michael S. Noble -------------------------------------------------------------------------- Version 0.5.11 (12/19/04): 1. Vwhere 1.2.4 enhancements: . use current plot zoom/shift as defaults when creating new plots . minor preferences tweaks 2. Contributed RGB widget now zeros its pixbuf prior to drawing, which eliminates UMRs (reported by Kenny Glotfelty, kjg@cfa.harvard.edu) 3. Bundle latest SLIRP version (1.5.0) 4. Migrate automated regression tests to use standalone TESS module 5. Initial support for S-Lang 2. 6. Show the S-Lang version number within the slgtk-demo main window. ------------------------------------ SLIRP: The S-Lang Interface Package Change Log mnoble@space.mit.edu ------------------------------------ Changes in v1.5.0 (Beta releases through 12/19/04) 1) Support function annotations, which provide powerful and flexible means of customizing the generated code. For example, a C function prototyped as having M inputs and N outputs may be called from S-Lang as though it were a function of M' inputs and N' outputs. 2) This is achieved by customizing the bundled slsh with the S-Lang preprocessor extension module (see ./preproc), and using it to add #argmap, #funcmap, #prototype, #retmap, #ignore, etc directives. 3) Add initial support for C++, which includes: . wrapping of overloaded functions and those with default values, but not templates or operators . generation of pure/standalone C wrappers from C++ code (i.e., containing no S-Lang C api calls) via new -cfront option Sample usage given in new ./examples/cpp directory. 4) Initial support for SLang 2 5) Macros may now be wrapped as if they were fully prototyped functions, via slirp_map_macro(). 6) Moved toggle_error_hook() function to new standalone test framework package [ TESS, the (Te)st (S)ystem for (S)-Lang] 7) Added default type mapping for void* and 'unsigned long int' types. 8) The distinction between arguments explicitly declared as arrays (e.g. float f[]) and those ambiguosly declared as arrays or refs (e.g. float *f) has been deprecated. Thus slirp_map_array() has also been deprecated. 9) Address bugs seen while parsing rather complex glibc headers (submitted by Paul Boekholt, paul@boekholt.com) 10) Perform macro substitutions upon args within function prototypes. 11) SLIRP now automatically maps all unknown types (be they function return values OR args within function parameter lists) to the opaquely-typed void_ptr. The new -noautotype option turns this off. 12) Prevent simultaneous loading of incompatible SLIRP-based modules, by introducing ABI version #, which will be checked at load time. 13) Sharpen the saw (resulting in better performance and smaller modules) . emit fewer, at times many, lines of code . perform only a single pass over input files . code is now emitted to a single file . obviating the -d switch, which has been eliminated . except for module init func, all generated funcs are now static . remove support for deprecated -consts, -init, and -opaques switches . better recognition of function pointer and enum args . exhibit use of new #ignore directive (2) in OpenGL and MySQL examples . strip "int" return types from C wrappers for FORTRAN subroutines (dburke@cfa.harvard.edu) From ben at versaccounting.com Wed Dec 22 15:27:46 2004 From: ben at versaccounting.com (Ben Duncan) Date: Tue Jan 30 08:52:04 2007 Subject: [slang-users] Accessing Functions using an array In-Reply-To: <200412121831.iBCIVEIP009567@aluche.mit.edu> References: <200412121831.iBCIVEIP009567@aluche.mit.edu> Message-ID: <41C9D8C2.8080402@versaccounting.com> Is it possible and how would you do it, to set up an array that contains function names (slang, not C) like such (pseudo code below): define functioname_1 { .....} define functioname_2 { .....} define functioname_3 { .....} ...... MyArray [10] ; MyArray[0] = "functioname_1" ; MyArray[1] = "functioname_2" ; MyArray[2] = "functioname_3" ; ..... ...... if(SELECTED != 0 ) do MyArray[SELECTED] .......... What I am trying to do is set an index to functions that the SLAG RAD/IDE generates. Each FUNCTION is really a "screen" to display. If the application contains more than one screen you would increment "SELECTED" and then the next screen would display. Thanks ... -- Ben Duncan - VersAccounting Software LLC 336 Elton Road Jackson MS, 39212 "Never attribute to malice, that which can be adequately explained by stupidity" - Hanlon's Razor From mnoble at space.mit.edu Wed Dec 22 15:35:58 2004 From: mnoble at space.mit.edu (Michael Noble) Date: Tue Jan 30 08:52:04 2007 Subject: [slang-users] Accessing Functions using an array In-Reply-To: <41C9D8C2.8080402@versaccounting.com> References: <200412121831.iBCIVEIP009567@aluche.mit.edu> <41C9D8C2.8080402@versaccounting.com> Message-ID: <20041222203558.GA2049@svoboda.mit.edu> > Is it possible and how would you do it, to set up an > array that contains function names (slang, not C) > like such (pseudo code below): > > define functioname_1 { .....} > define functioname_2 { .....} > define functioname_3 { .....} You probably want function references, not function names. In which case something like MyArray = [&functionname_1, &functionname_2, ...]; should suffice. There is a catch, however. In SLang 1 there exists a bug which prevents using the natural idiom (@MyArray[i]) (...); to invoke the i-th function within the array. Instead, one must use a temporary variable to store the function reference, then deref the variable to invoke the function, along the lines of variable func = MyArray[i]; (@func) (...); HTH, Mike From dburke at cfa.harvard.edu Wed Dec 22 15:34:41 2004 From: dburke at cfa.harvard.edu (Doug Burke) Date: Tue Jan 30 08:52:04 2007 Subject: [slang-users] Accessing Functions using an array In-Reply-To: <41C9D8C2.8080402@versaccounting.com> References: <200412121831.iBCIVEIP009567@aluche.mit.edu> <41C9D8C2.8080402@versaccounting.com> Message-ID: On Dec 22, 2004, at 3:27 PM, Ben Duncan wrote: > Is it possible and how would you do it, to set up an > array that contains function names (slang, not C) > like such (pseudo code below): > > define functioname_1 { .....} > define functioname_2 { .....} > define functioname_3 { .....} > ...... > > MyArray [10] ; > MyArray[0] = "functioname_1" ; > MyArray[1] = "functioname_2" ; > MyArray[2] = "functioname_3" ; > > ..... > ...... > > if(SELECTED != 0 ) > do MyArray[SELECTED] > .......... > > > What I am trying to do is set an index to functions that the SLAG > RAD/IDE > generates. Each FUNCTION is really a "screen" to display. If the > application > contains more than one screen you would increment "SELECTED" and then > the > next screen would display. Ben, If I understand you correctly then you want to use a reference to a function using the "&" operator and then call the routine by de-referencing the value using "@" (see also http://www.s-lang.org/doc/html/slang-3.html#ss3.3). Something like define bob () { message ("Hi, this is bob"); } define fred () { message ("I am fred"); } variable funcs = Ref_Type [2]; funcs [0] = &bob; funcs [1] = &fred; variable i = 1; @ funcs [i](); i--; @ funcs [i](); Will call the routines fred() and then bob(). If the routines took arguments then you can say '@ funcs [i] ( arg1, ..., argn );'. For situations like this I often use an 'Assoc_Type [Ref_Type]' array to store the function references, but it depends on how you want to access them. Hope this helps, Doug From ben at versaccounting.com Wed Dec 22 17:42:27 2004 From: ben at versaccounting.com (Ben Duncan) Date: Tue Jan 30 08:52:04 2007 Subject: [slang-users] Accessing Functions using an array In-Reply-To: <20041222203558.GA2049@svoboda.mit.edu> References: <200412121831.iBCIVEIP009567@aluche.mit.edu> <41C9D8C2.8080402@versaccounting.com> <20041222203558.GA2049@svoboda.mit.edu> Message-ID: <41C9F853.2020203@versaccounting.com> Michael / Doug - Perfect. That is exactly what I want to do. There has been a lot more interest of late in my SLAG project, so over the holidays, rather than be bored, I am back workin on it. The next biggie to get down is the Pull-down Menu system. FWIW, the look and feel so far has taken on something along the lines of Foxpro / Delphi / Alpha Four / Dbase / Paradox ..etc..etc.. Michael Noble wrote: >>Is it possible and how would you do it, to set up an >>array that contains function names (slang, not C) >>like such (pseudo code below): >> >>define functioname_1 { .....} >>define functioname_2 { .....} >>define functioname_3 { .....} > > > You probably want function references, not function names. > In which case something like > > MyArray = [&functionname_1, &functionname_2, ...]; > > should suffice. > > There is a catch, however. In SLang 1 there exists a bug > which prevents using the natural idiom > > (@MyArray[i]) (...); > > to invoke the i-th function within the array. Instead, one must > use a temporary variable to store the function reference, then > deref the variable to invoke the function, along the lines of > > variable func = MyArray[i]; > (@func) (...); > > HTH, > Mike > -- Ben Duncan - VersAccounting Software LLC 336 Elton Road Jackson MS, 39212 "Never attribute to malice, that which can be adequately explained by stupidity" - Hanlon's Razor From ben at versaccounting.com Mon Dec 27 21:30:19 2004 From: ben at versaccounting.com (Ben Duncan) Date: Tue Jan 30 08:52:04 2007 Subject: [slang-users] More efficient method ? In-Reply-To: <41C9F853.2020203@versaccounting.com> References: <200412121831.iBCIVEIP009567@aluche.mit.edu> <41C9D8C2.8080402@versaccounting.com> <20041222203558.GA2049@svoboda.mit.edu> <41C9F853.2020203@versaccounting.com> Message-ID: <41D0C53B.4080306@versaccounting.com> I am working on getting my pull down menu system written over the holidays. Which would be more efficient: A: storing a current image of the screen before opening another pop-up ( selection list of program or sub-menu) then restoring the screen image if the selection was made of a sub menu and they were backing out. or B: tracking which pop-up and selection was active before a new pop-up was made, and then do a whole menu re-process to put you back to where you were. I am also obligated to consider the aspects of what works well not only in TUI mode, but (eventually) what would lend itself workable in a true GRAPHICS mode. In AppGen, the PDEFS's themselves were eitheir called using a CHAIN (exec) or Fork, any suggestions there? Thanks, and Happy Holidays to all ... -- Ben Duncan - VersAccounting Software LLC 336 Elton Road Jackson MS, 39212 "Never attribute to malice, that which can be adequately explained by stupidity" - Hanlon's Razor