From joerg at alea.gnuu.de  Mon Aug 14 18:23:06 2006
From: joerg at alea.gnuu.de (=?iso-8859-1?Q?J=F6rg?= Sommer)
Date: Tue Jan 30 08:52:12 2007
Subject: [slang-users] Access redefined function
Message-ID: <slrnee1tu9.3h9.joerg@alea.gnuu.de>

Hi,

is it somehow possible to access a redefined function?

define foo()
{
   ...
}

variable old_foo = &foo();
define foo()
{
    ...
    @old_foo();
}

Bye, J?rg.
-- 
"UNIX was not designed to stop people from doing stupid things, because
 that would also stop them from doing clever things."
         -- Doug Gwyn


From davis at space.mit.edu  Mon Aug 14 22:01:50 2006
From: davis at space.mit.edu (John E. Davis)
Date: Tue Jan 30 08:52:12 2007
Subject: [slang-users] Access redefined function
In-Reply-To: <slrnee1tu9.3h9.joerg@alea.gnuu.de>
References: <slrnee1tu9.3h9.joerg@alea.gnuu.de>
Message-ID: <200608150201.k7F21oZF012265@aluche.mit.edu>

J?rg Sommer <joerg@alea.gnuu.de> wrote:
>is it somehow possible to access a redefined function?

Not yet-- I plan to add support for this but it is not very high on my
list.

--John


From joerg at alea.gnuu.de  Tue Aug 15 14:09:28 2006
From: joerg at alea.gnuu.de (=?iso-8859-1?Q?J=F6rg?= Sommer)
Date: Tue Jan 30 08:52:12 2007
Subject: [slang-users] Bug?: "$_NARGS"$
Message-ID: <slrnee43eo.3h9.joerg@alea.gnuu.de>

Hi,

should this work?

define fun()
{
    message("$_NARGS"$);
}

J?rg.
-- 
Dadurch, da? man einen anderen ins Irrenhaus sperrt,
beweist man noch nicht seinen eigenen Verstand.


From davis at space.mit.edu  Tue Aug 15 15:38:27 2006
From: davis at space.mit.edu (John E. Davis)
Date: Tue Jan 30 08:52:12 2007
Subject: [slang-users] Bug?: "$_NARGS"$
In-Reply-To: <slrnee43eo.3h9.joerg@alea.gnuu.de>
References: <slrnee43eo.3h9.joerg@alea.gnuu.de>
Message-ID: <200608151938.k7FJcRQH026660@aluche.mit.edu>

J?rg Sommer <joerg@alea.gnuu.de> wrote:
>should this work?
>
>define fun()
>{
>    message("$_NARGS"$);
>}

It works for me using slsh from slang 2.0.6 and pre2.0.7-50.  What
version are you using?  `slsh --version`

Thanks,
--John


From joerg at alea.gnuu.de  Wed Aug 16 09:12:15 2006
From: joerg at alea.gnuu.de (=?iso-8859-1?Q?J=F6rg?= Sommer)
Date: Tue Jan 30 08:52:12 2007
Subject: [slang-users] Bug?: "$_NARGS"$
References: <slrnee43eo.3h9.joerg@alea.gnuu.de>
	<200608151938.k7FJcRQH026660@aluche.mit.edu>
Message-ID: <slrnee66df.3h9.joerg@alea.gnuu.de>

Hello John,

"John E. Davis" <davis@space.mit.edu> wrote:
> J?rg Sommer <joerg@alea.gnuu.de> wrote:
>>should this work?
>>
>>define fun()
>>{
>>    message("$_NARGS"$);
>>}
>
> It works for me using slsh from slang 2.0.6 and pre2.0.7-50.  What
> version are you using?  `slsh --version`

Sorry. I take all back and claim the opposite. :-) I must have missed out
the dollar.

Bye, J?rg.
-- 
"Wer im Usenet gelesen werden will, sollte leserorientiert schreiben. Wer
nur f?r sich schreiben will, dem ist mit einem Tagebuch vielleicht besser
geholfen. Gelesen zu werden ist kein Recht, sondern ein Privileg."
  -- Thore Tams am 09.12.2000 in de.soc.netzkultur.umgangsformen


From joerg at alea.gnuu.de  Thu Aug 17 19:11:35 2006
From: joerg at alea.gnuu.de (=?iso-8859-1?Q?J=F6rg?= Sommer)
Date: Tue Jan 30 08:52:12 2007
Subject: [slang-users] keystring conversion to non UTF-8 string?
Message-ID: <slrnee9ttp.dcq.joerg@alea.gnuu.de>

Hi,

#v+
% cat test.c
#include <slang.h>
#include <stdio.h>

int main(void)
{
    const unsigned char *raw_seq = SLang_process_keystring("^/");

    for (int i=1; i < *raw_seq; ++i)
      printf("0x%02x ", raw_seq[i]);
    printf("\n");

    const char *key_str = SLang_make_keystring(raw_seq);
    do
      printf("0x%02x ", *key_str++);
    while (*key_str != '\0');
    printf("\n");

    return 0;
}

% ./test
0xef 
0xef 
#v-

Is this expected? Jed does not handle this case, e.g. it prints <EF> if
it runs in an UTF-8 termnial.

Bye, J?rg.
-- 
"...anytime you install something new on the Windows platform, you risk
spending the next five or six hours trying to figure out what happened"
         -- Robert Roblin, Adobe


From davis at space.mit.edu  Thu Aug 17 22:30:49 2006
From: davis at space.mit.edu (John E. Davis)
Date: Tue Jan 30 08:52:12 2007
Subject: [slang-users] keystring conversion to non UTF-8 string?
In-Reply-To: <slrnee9ttp.dcq.joerg@alea.gnuu.de>
References: <slrnee9ttp.dcq.joerg@alea.gnuu.de>
Message-ID: <200608180230.k7I2UnQW007474@aluche.mit.edu>

J?rg Sommer <joerg@alea.gnuu.de> wrote:
>int main(void)
>{
>    const unsigned char *raw_seq = SLang_process_keystring("^/");
[...]
>Is this expected? Jed does not handle this case, e.g. it prints <EF> if
>it runs in an UTF-8 termnial.

What should it print?  Strictly, speaking "^/" is not a real control
character.  The SLang_process_keystring converts ^X to an unsigned
byte value using the algorithm

   (unsigned char) (X - 'A' + 1)

This mechanism works for valid control characters ^A-^Z as well as ^@,
^[, ^\, ^], ^^, and ^_.  For ^/, the result is

   (unsigned char) ('/' - 'A' + 1)
    = (unsigned char) (-17)
    = 0xEF

This interface makes no attempt at converting bytes to characters.
That is, it does not produce the two byte sequence <C3><AF>.  Is that
what you were expecting?

Thanks,
--John


From joerg at alea.gnuu.de  Fri Aug 18 07:55:53 2006
From: joerg at alea.gnuu.de (=?iso-8859-1?Q?J=F6rg?= Sommer)
Date: Tue Jan 30 08:52:12 2007
Subject: [slang-users] keystring conversion to non UTF-8 string?
References: <slrnee9ttp.dcq.joerg@alea.gnuu.de>
	<200608180230.k7I2UnQW007474@aluche.mit.edu>
Message-ID: <slrneebaml.dcq.joerg@alea.gnuu.de>

Hello John,

"John E. Davis" <davis@space.mit.edu> wrote:
> J?rg Sommer <joerg@alea.gnuu.de> wrote:
>>int main(void)
>>{
>>    const unsigned char *raw_seq = SLang_process_keystring("^/");
> [...]
>>Is this expected? Jed does not handle this case, e.g. it prints <EF> if
>>it runs in an UTF-8 termnial.
>
> What should it print?

It should print ?.

> Strictly, speaking "^/" is not a real control character.

Ahh.

> The SLang_process_keystring converts ^X to an unsigned byte value using
> the algorithm
>
>    (unsigned char) (X - 'A' + 1)
>
> This mechanism works for valid control characters ^A-^Z as well as ^@,
> ^[, ^\, ^], ^^, and ^_.

Can you check for this range, e.g. >= '@' and <= '_'? And outside of this
range do nothing or throw an error. How else can I give the key sequence
"^X ^ /"?

> That is, it does not produce the two byte sequence <C3><AF>.  Is that
> what you were expecting?

Yes.

Bye, J?rg.
-- 
Dadurch, da? man einen anderen ins Irrenhaus sperrt,
beweist man noch nicht seinen eigenen Verstand.


From davis at space.mit.edu  Fri Aug 18 11:26:56 2006
From: davis at space.mit.edu (John E. Davis)
Date: Tue Jan 30 08:52:12 2007
Subject: [slang-users] keystring conversion to non UTF-8 string?
In-Reply-To: <slrneebaml.dcq.joerg@alea.gnuu.de>
References: <slrnee9ttp.dcq.joerg@alea.gnuu.de>
	<200608180230.k7I2UnQW007474@aluche.mit.edu>
	<slrneebaml.dcq.joerg@alea.gnuu.de>
Message-ID: <200608181526.k7IFQuJP018348@aluche.mit.edu>

J?rg Sommer <joerg@alea.gnuu.de> wrote:
>> The SLang_process_keystring converts ^X to an unsigned byte value using
>> the algorithm
>>
>>    (unsigned char) (X - 'A' + 1)
>>
>> This mechanism works for valid control characters ^A-^Z as well as ^@,
>> ^[, ^\, ^], ^^, and ^_.
>
>Can you check for this range, e.g. >= '@' and <= '_'? And outside of this
>range do nothing or throw an error. How else can I give the key sequence
>"^X ^ /"?

Unfortunately, there is no "escape" mechanism for using '^' in a
key-sequence except as the last character.  However, you can exploit
the algorithm to achieve the desired result.  In particular, the
key-sequence ^X ^ / may be represented by the string "^X^\x9E/", since
'^' = 0x9E-'A'+1.

--John



From grydholt at gmail.com  Tue Aug 22 17:50:03 2006
From: grydholt at gmail.com (Jacob Grydholt Jensen)
Date: Tue Jan 30 08:52:12 2007
Subject: [slang-users] Generating ruby bindings to s-lang using swig
Message-ID: <56b162b60608221450v6cd0f386o4ec40ea50b1ce673@mail.gmail.com>

Hi,

I would like to make ruby bindings to s-lang with swig. I am a newbie
at both s-lang and swig and my C is rusty, so please point me to
appropriate documentation
if I haven't done my homework properly.

I have created a slang.i file with the following content:

  %module slang
   %{
   /* Includes the header in the wrapper code */
   #include "/usr/local/include/slang.h"
   %}

   /* Parse the header file to generate wrappers */
   %include "/usr/local/include/slang.h"

And I run it as:

  $ swig -ruby slang.i
  /usr/local/include/slang.h:422: Warning(314): 'next' is a ruby
keyword, and it will renamed as 'C_next'
  /usr/local/include/slang.h:438: Warning(314): 'next' is a ruby
keyword, and it will renamed as 'C_next'
  /usr/local/include/slang.h:449: Warning(314): 'next' is a ruby
keyword, and it will renamed as 'C_next'
  /usr/local/include/slang.h:459: Warning(314): 'next' is a ruby
keyword, and it will renamed as 'C_next'
  /usr/local/include/slang.h:469: Warning(314): 'next' is a ruby
keyword, and it will renamed as 'C_next'
  /usr/local/include/slang.h:480: Warning(314): 'next' is a ruby
keyword, and it will renamed as 'C_next'
  /usr/local/include/slang.h:491: Warning(314): 'next' is a ruby
keyword, and it will renamed as 'C_next'
  /usr/local/include/slang.h:514: Warning(314): 'next' is a ruby
keyword, and it will renamed as 'C_next'
  /usr/local/include/slang.h:523: Warning(314): 'next' is a ruby
keyword, and it will renamed as 'C_next'
  /usr/local/include/slang.h:539: Error: Syntax error in input(1).
  /usr/local/include/slang.h:1432: Warning(454): Setting a
pointer/reference variable may leak memory.

I notice that swig reports an error in line 539, but it still
generates a slang_wrap.c file, which I try to compile with:

  $ gcc slang_wrap.c -I/usr/local/include
-I/usr/local/lib/ruby/1.8/arm-openbsd3.9
  slang_wrap.c: In function `field_name_get':
  slang_wrap.c:7309: error: `field_name' undeclared (first use in this function)
  slang_wrap.c:7309: error: (Each undeclared identifier is reported only once
  slang_wrap.c:7309: error: for each function it appears in.)
  slang_wrap.c: In function `field_name_set':
  slang_wrap.c:7322: error: `field_name' undeclared (first use in this function)
  slang_wrap.c: In function `offset_get':
  slang_wrap.c:7339: error: `offset' undeclared (first use in this function)
  slang_wrap.c: In function `offset_set':
  slang_wrap.c:7352: error: `offset' undeclared (first use in this function)
  slang_wrap.c: In function `type_get':
  slang_wrap.c:7364: error: `type' undeclared (first use in this function)
  slang_wrap.c: In function `type_set':
  slang_wrap.c:7377: error: `type' undeclared (first use in this function)
  slang_wrap.c: In function `read_only_get':
  slang_wrap.c:7389: error: `read_only' undeclared (first use in this function)
  slang_wrap.c: In function `read_only_set':
  slang_wrap.c:7402: error: `read_only' undeclared (first use in this function)

So obviously something went wrong. I guess the errors are related so I
will concentrate on the first with field_name. The file slang_wrap.c
has the following content in lines 7305 - 7312:

  SWIGINTERN VALUE
  field_name_get(VALUE self) {
    VALUE _val;

    _val = SWIG_FromCharPtr(field_name);
    return _val;
  }

I am running the following versions:

  $swig -version
  SWIG Version 1.3.29

  Compiled with g++ [zaurus-unknown-openbsd3.9]
  Please see http://www.swig.org for reporting bugs and further information

  $slsh --version
  slsh version 0.7.5-0
  S-Lang Library Version: 2.0.6

  $ ruby --version
  ruby 1.8.4 (2005-12-24) [arm-openbsd3.9]

--
/grydholt


From grydholt at gmail.com  Tue Aug 22 17:57:13 2006
From: grydholt at gmail.com (Jacob Grydholt Jensen)
Date: Tue Jan 30 08:52:12 2007
Subject: [slang-users] Generating ruby bindings to s-lang using swig
In-Reply-To: <56b162b60608221450v6cd0f386o4ec40ea50b1ce673@mail.gmail.com>
References: <56b162b60608221450v6cd0f386o4ec40ea50b1ce673@mail.gmail.com>
Message-ID: <56b162b60608221457n4d6ee50dtf1fb040828a555cf@mail.gmail.com>

I hate to reply to my own post, but I think I left out some important
information:

>   /usr/local/include/slang.h:523: Warning(314): 'next' is a ruby
> keyword, and it will renamed as 'C_next'
>   /usr/local/include/slang.h:539: Error: Syntax error in input(1).
>   /usr/local/include/slang.h:1432: Warning(454): Setting a
> pointer/reference variable may leak memory.

So swig does not like line 539. The slang.h file lines 538 - 545:

  typedef SLCONST struct _pSLang_CStruct_Field_Type   /* a g++ bug?? yuk*/
  {
     char *field_name;
     unsigned int offset;
     SLtype type;
     unsigned char read_only;
  }
  SLang_CStruct_Field_Type;

I know it is a long shot, but could the cause of the comment above
have anything to do with the error I see?
--
/grydholt


From mnoble at space.mit.edu  Wed Aug 23 20:03:18 2006
From: mnoble at space.mit.edu (Michael Noble)
Date: Tue Jan 30 08:52:12 2007
Subject: [slang-users] HDF5 module released
Message-ID: <20060824000318.GA13979@svoboda.mit.edu>

S-Lang Friends,

The first public release of the HDF5 module is now available:

   http://space.mit.edu/cxc/software/slang/modules/slh5
	
HDF5 is widely used in data- and CPU-intensive science and engineering
projects -- such as the FLASH simulator of thermonuclear explosions in
stars -- because it combines data and compiler portability with very
high performance, scalability to terabyte-size datasets, and support
for parallel I/O.

SLh5 boils the complexity of the HDF5 interface -- which consists of
hundreds of functions -- down to a few simple methods, making it very
easy to create S-Lang arrays from HDF5 files or vice versa.  With one
exception, the top-level SLh5 interface has been vectorized by the
SLIRP code generator; this allows multiple HDF5 files to be opened or
created, or multiple datasets or attributes to be read, in a single
call.

Scientific users may thus incorporate HDF5 data within S-Lang based
analyis applications such as ISIS, with substantially smaller and
cleaner code than is possible through other means, e.g. IDL (tm), and
with potentially considerable I/O performance advantages.  For
example, as described at

   http://space.mit.edu/CXC/software/slang/modules/slirp/vec-hdf5.pdf

we've used SLh5 internally to read the adaptive mesh refinement output
of hydrodynamics simulations generated by FLASH.  The AMR reader based
on SLh5 is markedly shorter and faster than the IDL (tm) FLASH reader,
and facilitates the use of hydro simulations as source models for multi-
dimensional modeling experiments in ISIS.  We've also employed HDF5 as
the transport format for 3D volume data used for visualization and
qualitative diagnostics in such modeling, and are looking for other
potential use cases from the X-ray community.

Regards,
Michael S. Noble