sexpr-users Mailing List for sexpr
Brought to you by:
matts22
You can subscribe to this list here.
2004 |
Jan
|
Feb
(3) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
|
Apr
(5) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Matthew S. <mjs...@me...> - 2010-06-02 06:53:49
|
Hello all- A new version was released today (v1.2.1). It does not provide any significant feature updates or bug fixes other than to address some problems observed in recent Ubuntu releases where the examples were not compiling anymore thanks to a missing parameter to open() in examples/binmode.c. Everything in 1.2.1 compiles fine now, and has been tested on recent OSX and Linux systems (Ubuntu 10.04). It's been 3 years since 1.2 came out -- a release was due at some point in the near future anyways to prove that the project isn't dead and abandoned. :-) -matt |
From: Matthew S. <mjs...@ma...> - 2010-04-27 21:02:52
|
No problem - I'm always happy to help anyone who finds the library to be useful. -m On Tuesday, April 27, 2010, at 01:51PM, "Hoover, Ryan L CTR USAF AFMC AFRL/RDSM" <Ryan.Hoover.CTR@Maui.AFMC.AF.MIL> wrote: >Hi Matt, > >Thanks for the excellent help. Adding the cygwin libraries solved the >problem. > >Almost all the websites I need to do my job are locally blocked. > >I'm sorry to have bothered you about this. > > >Micah Hoover > >-----Original Message----- >From: Matthew Sottile [mailto:mjs...@ma...] >Sent: Wednesday, April 21, 2010 9:17 PM >To: Hoover, Ryan L CTR USAF AFMC AFRL/RDSM >Cc: sex...@li... >Subject: Re: [Sexpr-users] building sexp with cygwin > >Hi! > >I don't know the answer off hand as I haven't tried the library with >cygwin/mingw in many, many years. A quick search online turns this up >though: > >http://lucksus.org/2009/02/12/cygwin-and-undefined-reference-to-__getree >nt/ > >It looks like you may be missing some libraries, like libcygwin.a. Have >you tried explicitly adding the -lcygwin argument to the link line >(possibly with an accompanying -L argument to make sure the library can >be found)? > >That may also fix the assert problem -- it looks like the implementation >of both functions (getreent and assert_func) are not being found at link >time, and they seem to be part of the cygwin libraries. > >Let me know if that helps. If not, I'll try to reproduce it and dig >deeper. > >-matt > >On Apr 21, 2010, at 5:42 PM, Hoover, Ryan L CTR USAF AFMC AFRL/RDSM >wrote: > >> Hello sexpr users, >> >> I'm trying to find a way to build libsexp.a on a Windows machine and >then link this library into an application. >> >> I used cygwin to configure sexp. Then I used the mingw that came with >Qt to build the library. This appeared to be a success. >> >> When I tried to link my project to this library, though (using the >same mingw compiler) I got this response: >> >> Warning: .drectve '-aligncomm:_pd_cache,2 ' unrecognized >> Warning: .drectve '-aligncomm:_sexp_t_cache,2 ' unrecognized >> Warning: .drectve '-aligncomm:___CTOR_LIST__,2 ' unrecognized >> Warning: .drectve '-aligncomm:___DTOR_LIST__,2 ' unrecognized >> >C:\cygwin\opt\sexp\lib/libsexp.a(event_temp.o):event_temp.cL.text+0x18f) >: undefined reference to '__getreent' >> >C:\cygwin\opt\sexp\lib/libsexp.a(event_temp.o):event_temp.cL.text+0x18f) >: undefined reference to '__assert_func' >> >C:\cygwin\opt\sexp\lib/libsexp.a(event_temp.o):event_temp.cL.text+0x18f) >: undefined reference to '__assert_func' >> >C:\cygwin\opt\sexp\lib/libsexp.a(event_temp.o):event_temp.cL.text+0x18f) >: undefined reference to '__assert_func' >> >C:\cygwin\opt\sexp\lib/libsexp.a(event_temp.o):event_temp.cL.text+0x18f) >: undefined reference to '__assert_func' >> >C:\cygwin\opt\sexp\lib/libsexp.a(event_temp.o):event_temp.cL.text+0x18f) >: undefined reference to '__assert_func' >> Undefined references to '__assert_func' follow >> >> I'm guessing part of this stems from <assert.h> not getting linked in >or found somehow. I've tried putting assert.h in the build directory and >the source directory. This didn't work. >> >> I've thought about removing the 14 or so references to "assert" in >event_temp.c (since this is only called if something is wrong, right?), >but I don't know if there's a clean way to do this. Also, I'm not sure >about how to resolve the __getreent reference (I couldn't find this >anywhere in event_temp). >> >> Any ideas? >> >> >> Micah Hoover >> >> >------------------------------------------------------------------------ >------ >> _______________________________________________ >> Sexpr-users mailing list >> Sex...@li... >> https://lists.sourceforge.net/lists/listinfo/sexpr-users > > >------------------------------------------------------------------------------ >_______________________________________________ >Sexpr-users mailing list >Sex...@li... >https://lists.sourceforge.net/lists/listinfo/sexpr-users > > |
From: Matthew S. <mjs...@ma...> - 2010-04-27 21:02:36
|
No problem - I'm always happy to help anyone who finds the library to be useful. -m On Tuesday, April 27, 2010, at 01:51PM, "Hoover, Ryan L CTR USAF AFMC AFRL/RDSM" <Ryan.Hoover.CTR@Maui.AFMC.AF.MIL> wrote: >Hi Matt, > >Thanks for the excellent help. Adding the cygwin libraries solved the >problem. > >Almost all the websites I need to do my job are locally blocked. > >I'm sorry to have bothered you about this. > > >Micah Hoover > >-----Original Message----- >From: Matthew Sottile [mailto:mjs...@ma...] >Sent: Wednesday, April 21, 2010 9:17 PM >To: Hoover, Ryan L CTR USAF AFMC AFRL/RDSM >Cc: sex...@li... >Subject: Re: [Sexpr-users] building sexp with cygwin > >Hi! > >I don't know the answer off hand as I haven't tried the library with >cygwin/mingw in many, many years. A quick search online turns this up >though: > >http://lucksus.org/2009/02/12/cygwin-and-undefined-reference-to-__getree >nt/ > >It looks like you may be missing some libraries, like libcygwin.a. Have >you tried explicitly adding the -lcygwin argument to the link line >(possibly with an accompanying -L argument to make sure the library can >be found)? > >That may also fix the assert problem -- it looks like the implementation >of both functions (getreent and assert_func) are not being found at link >time, and they seem to be part of the cygwin libraries. > >Let me know if that helps. If not, I'll try to reproduce it and dig >deeper. > >-matt > >On Apr 21, 2010, at 5:42 PM, Hoover, Ryan L CTR USAF AFMC AFRL/RDSM >wrote: > >> Hello sexpr users, >> >> I'm trying to find a way to build libsexp.a on a Windows machine and >then link this library into an application. >> >> I used cygwin to configure sexp. Then I used the mingw that came with >Qt to build the library. This appeared to be a success. >> >> When I tried to link my project to this library, though (using the >same mingw compiler) I got this response: >> >> Warning: .drectve '-aligncomm:_pd_cache,2 ' unrecognized >> Warning: .drectve '-aligncomm:_sexp_t_cache,2 ' unrecognized >> Warning: .drectve '-aligncomm:___CTOR_LIST__,2 ' unrecognized >> Warning: .drectve '-aligncomm:___DTOR_LIST__,2 ' unrecognized >> >C:\cygwin\opt\sexp\lib/libsexp.a(event_temp.o):event_temp.cL.text+0x18f) >: undefined reference to '__getreent' >> >C:\cygwin\opt\sexp\lib/libsexp.a(event_temp.o):event_temp.cL.text+0x18f) >: undefined reference to '__assert_func' >> >C:\cygwin\opt\sexp\lib/libsexp.a(event_temp.o):event_temp.cL.text+0x18f) >: undefined reference to '__assert_func' >> >C:\cygwin\opt\sexp\lib/libsexp.a(event_temp.o):event_temp.cL.text+0x18f) >: undefined reference to '__assert_func' >> >C:\cygwin\opt\sexp\lib/libsexp.a(event_temp.o):event_temp.cL.text+0x18f) >: undefined reference to '__assert_func' >> >C:\cygwin\opt\sexp\lib/libsexp.a(event_temp.o):event_temp.cL.text+0x18f) >: undefined reference to '__assert_func' >> Undefined references to '__assert_func' follow >> >> I'm guessing part of this stems from <assert.h> not getting linked in >or found somehow. I've tried putting assert.h in the build directory and >the source directory. This didn't work. >> >> I've thought about removing the 14 or so references to "assert" in >event_temp.c (since this is only called if something is wrong, right?), >but I don't know if there's a clean way to do this. Also, I'm not sure >about how to resolve the __getreent reference (I couldn't find this >anywhere in event_temp). >> >> Any ideas? >> >> >> Micah Hoover >> >> >------------------------------------------------------------------------ >------ >> _______________________________________________ >> Sexpr-users mailing list >> Sex...@li... >> https://lists.sourceforge.net/lists/listinfo/sexpr-users > > >------------------------------------------------------------------------------ >_______________________________________________ >Sexpr-users mailing list >Sex...@li... >https://lists.sourceforge.net/lists/listinfo/sexpr-users > > |
From: Hoover,
Ryan L C. U. A. AFRL/R. <Ryan.Hoover.CTR@Maui.AFMC.AF.MIL> - 2010-04-27 20:51:44
|
Hi Matt, Thanks for the excellent help. Adding the cygwin libraries solved the problem. Almost all the websites I need to do my job are locally blocked. I'm sorry to have bothered you about this. Micah Hoover -----Original Message----- From: Matthew Sottile [mailto:mjs...@ma...] Sent: Wednesday, April 21, 2010 9:17 PM To: Hoover, Ryan L CTR USAF AFMC AFRL/RDSM Cc: sex...@li... Subject: Re: [Sexpr-users] building sexp with cygwin Hi! I don't know the answer off hand as I haven't tried the library with cygwin/mingw in many, many years. A quick search online turns this up though: http://lucksus.org/2009/02/12/cygwin-and-undefined-reference-to-__getree nt/ It looks like you may be missing some libraries, like libcygwin.a. Have you tried explicitly adding the -lcygwin argument to the link line (possibly with an accompanying -L argument to make sure the library can be found)? That may also fix the assert problem -- it looks like the implementation of both functions (getreent and assert_func) are not being found at link time, and they seem to be part of the cygwin libraries. Let me know if that helps. If not, I'll try to reproduce it and dig deeper. -matt On Apr 21, 2010, at 5:42 PM, Hoover, Ryan L CTR USAF AFMC AFRL/RDSM wrote: > Hello sexpr users, > > I'm trying to find a way to build libsexp.a on a Windows machine and then link this library into an application. > > I used cygwin to configure sexp. Then I used the mingw that came with Qt to build the library. This appeared to be a success. > > When I tried to link my project to this library, though (using the same mingw compiler) I got this response: > > Warning: .drectve '-aligncomm:_pd_cache,2 ' unrecognized > Warning: .drectve '-aligncomm:_sexp_t_cache,2 ' unrecognized > Warning: .drectve '-aligncomm:___CTOR_LIST__,2 ' unrecognized > Warning: .drectve '-aligncomm:___DTOR_LIST__,2 ' unrecognized > C:\cygwin\opt\sexp\lib/libsexp.a(event_temp.o):event_temp.cL.text+0x18f) : undefined reference to '__getreent' > C:\cygwin\opt\sexp\lib/libsexp.a(event_temp.o):event_temp.cL.text+0x18f) : undefined reference to '__assert_func' > C:\cygwin\opt\sexp\lib/libsexp.a(event_temp.o):event_temp.cL.text+0x18f) : undefined reference to '__assert_func' > C:\cygwin\opt\sexp\lib/libsexp.a(event_temp.o):event_temp.cL.text+0x18f) : undefined reference to '__assert_func' > C:\cygwin\opt\sexp\lib/libsexp.a(event_temp.o):event_temp.cL.text+0x18f) : undefined reference to '__assert_func' > C:\cygwin\opt\sexp\lib/libsexp.a(event_temp.o):event_temp.cL.text+0x18f) : undefined reference to '__assert_func' > Undefined references to '__assert_func' follow > > I'm guessing part of this stems from <assert.h> not getting linked in or found somehow. I've tried putting assert.h in the build directory and the source directory. This didn't work. > > I've thought about removing the 14 or so references to "assert" in event_temp.c (since this is only called if something is wrong, right?), but I don't know if there's a clean way to do this. Also, I'm not sure about how to resolve the __getreent reference (I couldn't find this anywhere in event_temp). > > Any ideas? > > > Micah Hoover > > ------------------------------------------------------------------------ ------ > _______________________________________________ > Sexpr-users mailing list > Sex...@li... > https://lists.sourceforge.net/lists/listinfo/sexpr-users |
From: Matthew S. <mjs...@ma...> - 2010-04-22 07:17:30
|
Hi! I don't know the answer off hand as I haven't tried the library with cygwin/mingw in many, many years. A quick search online turns this up though: http://lucksus.org/2009/02/12/cygwin-and-undefined-reference-to-__getreent/ It looks like you may be missing some libraries, like libcygwin.a. Have you tried explicitly adding the -lcygwin argument to the link line (possibly with an accompanying -L argument to make sure the library can be found)? That may also fix the assert problem -- it looks like the implementation of both functions (getreent and assert_func) are not being found at link time, and they seem to be part of the cygwin libraries. Let me know if that helps. If not, I'll try to reproduce it and dig deeper. -matt On Apr 21, 2010, at 5:42 PM, Hoover, Ryan L CTR USAF AFMC AFRL/RDSM wrote: > Hello sexpr users, > > I’m trying to find a way to build libsexp.a on a Windows machine and then link this library into an application. > > I used cygwin to configure sexp. Then I used the mingw that came with Qt to build the library. This appeared to be a success. > > When I tried to link my project to this library, though (using the same mingw compiler) I got this response: > > Warning: .drectve ‘-aligncomm:_pd_cache,2 ‘ unrecognized > Warning: .drectve ‘-aligncomm:_sexp_t_cache,2 ‘ unrecognized > Warning: .drectve ‘-aligncomm:___CTOR_LIST__,2 ‘ unrecognized > Warning: .drectve ‘-aligncomm:___DTOR_LIST__,2 ‘ unrecognized > C:\cygwin\opt\sexp\lib/libsexp.a(event_temp.o):event_temp.cL.text+0x18f): undefined reference to ‘__getreent’ > C:\cygwin\opt\sexp\lib/libsexp.a(event_temp.o):event_temp.cL.text+0x18f): undefined reference to ‘__assert_func’ > C:\cygwin\opt\sexp\lib/libsexp.a(event_temp.o):event_temp.cL.text+0x18f): undefined reference to ‘__assert_func’ > C:\cygwin\opt\sexp\lib/libsexp.a(event_temp.o):event_temp.cL.text+0x18f): undefined reference to ‘__assert_func’ > C:\cygwin\opt\sexp\lib/libsexp.a(event_temp.o):event_temp.cL.text+0x18f): undefined reference to ‘__assert_func’ > C:\cygwin\opt\sexp\lib/libsexp.a(event_temp.o):event_temp.cL.text+0x18f): undefined reference to ‘__assert_func’ > Undefined references to ‘__assert_func’ follow > > I’m guessing part of this stems from <assert.h> not getting linked in or found somehow. I’ve tried putting assert.h in the build directory and the source directory. This didn’t work. > > I’ve thought about removing the 14 or so references to “assert” in event_temp.c (since this is only called if something is wrong, right?), but I don’t know if there’s a clean way to do this. Also, I’m not sure about how to resolve the __getreent reference (I couldn’t find this anywhere in event_temp). > > Any ideas? > > > Micah Hoover > Engineering Scientist II > Boeing LTS > (808) 874-1528 > > ------------------------------------------------------------------------------ > _______________________________________________ > Sexpr-users mailing list > Sex...@li... > https://lists.sourceforge.net/lists/listinfo/sexpr-users |
From: Hoover,
Ryan L C. U. A. AFRL/R. <Ryan.Hoover.CTR@Maui.AFMC.AF.MIL> - 2010-04-22 00:57:06
|
Hello sexpr users, I'm trying to find a way to build libsexp.a on a Windows machine and then link this library into an application. I used cygwin to configure sexp. Then I used the mingw that came with Qt to build the library. This appeared to be a success. When I tried to link my project to this library, though (using the same mingw compiler) I got this response: Warning: .drectve '-aligncomm:_pd_cache,2 ' unrecognized Warning: .drectve '-aligncomm:_sexp_t_cache,2 ' unrecognized Warning: .drectve '-aligncomm:___CTOR_LIST__,2 ' unrecognized Warning: .drectve '-aligncomm:___DTOR_LIST__,2 ' unrecognized C:\cygwin\opt\sexp\lib/libsexp.a(event_temp.o):event_temp.cL.text+0x18f) : undefined reference to '__getreent' C:\cygwin\opt\sexp\lib/libsexp.a(event_temp.o):event_temp.cL.text+0x18f) : undefined reference to '__assert_func' C:\cygwin\opt\sexp\lib/libsexp.a(event_temp.o):event_temp.cL.text+0x18f) : undefined reference to '__assert_func' C:\cygwin\opt\sexp\lib/libsexp.a(event_temp.o):event_temp.cL.text+0x18f) : undefined reference to '__assert_func' C:\cygwin\opt\sexp\lib/libsexp.a(event_temp.o):event_temp.cL.text+0x18f) : undefined reference to '__assert_func' C:\cygwin\opt\sexp\lib/libsexp.a(event_temp.o):event_temp.cL.text+0x18f) : undefined reference to '__assert_func' Undefined references to '__assert_func' follow I'm guessing part of this stems from <assert.h> not getting linked in or found somehow. I've tried putting assert.h in the build directory and the source directory. This didn't work. I've thought about removing the 14 or so references to "assert" in event_temp.c (since this is only called if something is wrong, right?), but I don't know if there's a clean way to do this. Also, I'm not sure about how to resolve the __getreent reference (I couldn't find this anywhere in event_temp). Any ideas? Micah Hoover Engineering Scientist II Boeing LTS (808) 874-1528 |
From: Matthew S. <mjs...@me...> - 2009-08-15 10:11:03
|
That would be good news if the sfsexp code isn't causing the problem. I'm really glad to hear you and your co-workers are finding the library to be useful. I have been meaning to make a new release for a while since the last one was in late 2007. Are there any areas where you guys would like to see fixes/updates to address any outstanding problems or annoyances in the current version of the code? Would any specific examples be useful to be included in the distribution to demonstrate the library being used in specific contexts? By the way, would it be possible to describe what you all are using the library for? I'm always curious to hear what context people find the code to be useful in. I know that I had some happy users at the Starfire Optical Range at Kirtland AFB a few years back, and am curious if your work is related to that or not. -m On Aug 14, 2009, at 12:51 PM, Hoover, Ryan L CTR USAF AFMC AFRL/RDSM wrote: > Hi Matt, > > I had the same problem. I put together a simple C version of the > expression and ran it 10,000 without crashing. I did some further > stress tests and found the program crashed in places other than > parse_sexp() (which I had assumed indicated a sexp.h bug). It was > crashing while allocating and deallocating the string. It was so non- > deterministic I began to suspect the scheduler/threading mechanisms > (I had the parser along with the UDP transport client in a separate > thread just to make things a little smoother for the end user). So I > put the parser/transport client into the same thread and the > problems went away. (Also due to learning more about nonblocking > select statements and recvfrom calls it turned out to be about as > smooth). Qt works great -it may be I don’t fully understand which > objects live in which threads- but I wonder if it has contributed to > the problem. Anyway, I currently believe SFSexp has nothing to do > with the problems I was seeing. > > Sorry to all the folks I may have bothered with my issue. I can’t > believe I got a response from Matthew Sottile!! Many of my coworkers > here believe strongly in SFSexp and it’s becoming something of a > site standard. > > > Matt Canonicus > Hawaii > > From: Matthew Sottile [mailto:mjs...@me...] > Sent: Thursday, August 13, 2009 10:09 PM > To: Hoover, Ryan L CTR USAF AFMC AFRL/RDSM > Cc: sex...@li... > Subject: Re: [Sexpr-users] parse_sexp crashes > > Hi- > > I'd be happy to help track down the source of this error that you > are seeing. I passed the same string to a simple program myself and > it worked just fine as you saw. I am assuming the crash you are > seeing is a side effect of how the parser is interacting with the > rest of the program that you are writing. Do you have a simple > program that can reproduce the circumstances where a segmentation > fault occurs? > > Are you using the standard build of the library (ie: you just ran > "make" with no special target), or are you using the special > versions (like "make limitmem")? > > Any details you can provide would be helpful so I can try to > reproduce the bug and either debug the library or give you pointers > on properly using the code. I'm always happy to give users a hand > if they find my little library useful! :-) > > -matt > > On Aug 13, 2009, at 1:34 PM, Hoover, Ryan L CTR USAF AFMC > AFRL/RDSM wrote: > > > I’m new to sfsexp and mailing lists in general so please go easy on > me ;) > > SFSexp works great most of the time for me, but there are occasions > where parse_sexp() seg faults. > > I have confirmed from my Qt version of GDB that this is exactly what > I’m passing to parse_sexp: > > 0x8b287b8 "(DataKeyValue (oss (xenon-lamp (state OFF) (level 0) > (color GRAY) (error NO-ERROR)) (laser-diode (state OFF) (level 0) > (color GRAY) (error NO-ERROR)) (resolution-target (state OFF) (pos > 0) (color GREEN) (error NO-ERROR)) (target-aperture (state RESET) > (pos 0) (color GRAY) (error NO-ERROR)) (phase-plate (state RESET) > (pos 0) (color GRAY) (error NO-ERROR)) (injection-mirror (state > RESET) (pos -10) (color GREEN) (error NO-ERROR)) (background (state > RESET) (pos 0) (color GRAY) (error NO-ERROR)) (target-brightness1 > (state RESET) (pos 0) (color GRAY) (error NO-ERROR)) (target- > brightness2 (state RESET) (pos 0) (color GRAY) (error NO-ERROR)) ))" > > (Note the 0x8b287b8 and quotation marks are artifacts of the > debugger and not part of the string). > > When I look up the backtrace stack I see some malloc’s, so I tried > allocating the char array a couple similar (but identical) ways, but > to no success. Also, I wrote a simple program that just calls > parse_sexp() on this string and it does NOT crash. I’m very confused > on this one. > > Thanks for your help! > > > c > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and > focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july_______________________________________________ > Sexpr-users mailing list > Sex...@li... > https://lists.sourceforge.net/lists/listinfo/sexpr-users > |
From: Hoover,
Ryan L C. U. A. AFRL/R. <Ryan.Hoover.CTR@Maui.AFMC.AF.MIL> - 2009-08-14 19:52:05
|
Hi Matt, I had the same problem. I put together a simple C version of the expression and ran it 10,000 without crashing. I did some further stress tests and found the program crashed in places other than parse_sexp() (which I had assumed indicated a sexp.h bug). It was crashing while allocating and deallocating the string. It was so non-deterministic I began to suspect the scheduler/threading mechanisms (I had the parser along with the UDP transport client in a separate thread just to make things a little smoother for the end user). So I put the parser/transport client into the same thread and the problems went away. (Also due to learning more about nonblocking select statements and recvfrom calls it turned out to be about as smooth). Qt works great -it may be I don't fully understand which objects live in which threads- but I wonder if it has contributed to the problem. Anyway, I currently believe SFSexp has nothing to do with the problems I was seeing. Sorry to all the folks I may have bothered with my issue. I can't believe I got a response from Matthew Sottile!! Many of my coworkers here believe strongly in SFSexp and it's becoming something of a site standard. Matt Canonicus Hawaii From: Matthew Sottile [mailto:mjs...@me...] Sent: Thursday, August 13, 2009 10:09 PM To: Hoover, Ryan L CTR USAF AFMC AFRL/RDSM Cc: sex...@li... Subject: Re: [Sexpr-users] parse_sexp crashes Hi- I'd be happy to help track down the source of this error that you are seeing. I passed the same string to a simple program myself and it worked just fine as you saw. I am assuming the crash you are seeing is a side effect of how the parser is interacting with the rest of the program that you are writing. Do you have a simple program that can reproduce the circumstances where a segmentation fault occurs? Are you using the standard build of the library (ie: you just ran "make" with no special target), or are you using the special versions (like "make limitmem")? Any details you can provide would be helpful so I can try to reproduce the bug and either debug the library or give you pointers on properly using the code. I'm always happy to give users a hand if they find my little library useful! :-) -matt On Aug 13, 2009, at 1:34 PM, Hoover, Ryan L CTR USAF AFMC AFRL/RDSM wrote: I'm new to sfsexp and mailing lists in general so please go easy on me ;) SFSexp works great most of the time for me, but there are occasions where parse_sexp() seg faults. I have confirmed from my Qt version of GDB that this is exactly what I'm passing to parse_sexp: 0x8b287b8 "(DataKeyValue (oss (xenon-lamp (state OFF) (level 0) (color GRAY) (error NO-ERROR)) (laser-diode (state OFF) (level 0) (color GRAY) (error NO-ERROR)) (resolution-target (state OFF) (pos 0) (color GREEN) (error NO-ERROR)) (target-aperture (state RESET) (pos 0) (color GRAY) (error NO-ERROR)) (phase-plate (state RESET) (pos 0) (color GRAY) (error NO-ERROR)) (injection-mirror (state RESET) (pos -10) (color GREEN) (error NO-ERROR)) (background (state RESET) (pos 0) (color GRAY) (error NO-ERROR)) (target-brightness1 (state RESET) (pos 0) (color GRAY) (error NO-ERROR)) (target-brightness2 (state RESET) (pos 0) (color GRAY) (error NO-ERROR)) ))" (Note the 0x8b287b8 and quotation marks are artifacts of the debugger and not part of the string). When I look up the backtrace stack I see some malloc's, so I tried allocating the char array a couple similar (but identical) ways, but to no success. Also, I wrote a simple program that just calls parse_sexp() on this string and it does NOT crash. I'm very confused on this one. Thanks for your help! c ---------------------------------------------------------------------------- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july_______________________________________________ Sexpr-users mailing list Sex...@li... https://lists.sourceforge.net/lists/listinfo/sexpr-users |
From: Matthew S. <mjs...@me...> - 2009-08-14 08:09:43
|
Hi- I'd be happy to help track down the source of this error that you are seeing. I passed the same string to a simple program myself and it worked just fine as you saw. I am assuming the crash you are seeing is a side effect of how the parser is interacting with the rest of the program that you are writing. Do you have a simple program that can reproduce the circumstances where a segmentation fault occurs? Are you using the standard build of the library (ie: you just ran "make" with no special target), or are you using the special versions (like "make limitmem")? Any details you can provide would be helpful so I can try to reproduce the bug and either debug the library or give you pointers on properly using the code. I'm always happy to give users a hand if they find my little library useful! :-) -matt On Aug 13, 2009, at 1:34 PM, Hoover, Ryan L CTR USAF AFMC AFRL/RDSM wrote: > I’m new to sfsexp and mailing lists in general so please go easy on > me ;) > > SFSexp works great most of the time for me, but there are occasions > where parse_sexp() seg faults. > > I have confirmed from my Qt version of GDB that this is exactly what > I’m passing to parse_sexp: > > 0x8b287b8 "(DataKeyValue (oss (xenon-lamp (state OFF) (level 0) > (color GRAY) (error NO-ERROR)) (laser-diode (state OFF) (level 0) > (color GRAY) (error NO-ERROR)) (resolution-target (state OFF) (pos > 0) (color GREEN) (error NO-ERROR)) (target-aperture (state RESET) > (pos 0) (color GRAY) (error NO-ERROR)) (phase-plate (state RESET) > (pos 0) (color GRAY) (error NO-ERROR)) (injection-mirror (state > RESET) (pos -10) (color GREEN) (error NO-ERROR)) (background (state > RESET) (pos 0) (color GRAY) (error NO-ERROR)) (target-brightness1 > (state RESET) (pos 0) (color GRAY) (error NO-ERROR)) (target- > brightness2 (state RESET) (pos 0) (color GRAY) (error NO-ERROR)) ))" > > (Note the 0x8b287b8 and quotation marks are artifacts of the > debugger and not part of the string). > > When I look up the backtrace stack I see some malloc’s, so I tried > allocating the char array a couple similar (but identical) ways, but > to no success. Also, I wrote a simple program that just calls > parse_sexp() on this string and it does NOT crash. I’m very confused > on this one. > > Thanks for your help! > > > Matt Canonicus > Hawaii > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and > focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july_______________________________________________ > Sexpr-users mailing list > Sex...@li... > https://lists.sourceforge.net/lists/listinfo/sexpr-users |
From: Hoover,
Ryan L C. U. A. AFRL/R. <Ryan.Hoover.CTR@Maui.AFMC.AF.MIL> - 2009-08-13 20:49:23
|
I'm new to sfsexp and mailing lists in general so please go easy on me ;) SFSexp works great most of the time for me, but there are occasions where parse_sexp() seg faults. I have confirmed from my Qt version of GDB that this is exactly what I'm passing to parse_sexp: 0x8b287b8 "(DataKeyValue (oss (xenon-lamp (state OFF) (level 0) (color GRAY) (error NO-ERROR)) (laser-diode (state OFF) (level 0) (color GRAY) (error NO-ERROR)) (resolution-target (state OFF) (pos 0) (color GREEN) (error NO-ERROR)) (target-aperture (state RESET) (pos 0) (color GRAY) (error NO-ERROR)) (phase-plate (state RESET) (pos 0) (color GRAY) (error NO-ERROR)) (injection-mirror (state RESET) (pos -10) (color GREEN) (error NO-ERROR)) (background (state RESET) (pos 0) (color GRAY) (error NO-ERROR)) (target-brightness1 (state RESET) (pos 0) (color GRAY) (error NO-ERROR)) (target-brightness2 (state RESET) (pos 0) (color GRAY) (error NO-ERROR)) ))" (Note the 0x8b287b8 and quotation marks are artifacts of the debugger and not part of the string). When I look up the backtrace stack I see some malloc's, so I tried allocating the char array a couple similar (but identical) ways, but to no success. Also, I wrote a simple program that just calls parse_sexp() on this string and it does NOT crash. I'm very confused on this one. Thanks for your help! Matt Canonicus Hawaii |
From: Matthew S. <ma...@cs...> - 2007-10-25 08:26:45
|
Greetings. A new version of the sfsexp s-expression parser library has been released. The new version includes enhancements to the error handling facilities of the library and various bug fixes and code cleanup. Detailed information can be found on the project web page at: http://sexpr.sourceforge.net/ -m |
From: Matthew S. <mjs...@ma...> - 2005-06-04 20:50:31
|
Thanks- I'll update the code for the upcoming release to make these changes. I'll also look around to see if any other parts of the API might also require this change. -m On May 28, 2005, at 3:55 AM, Richard Spindler wrote: > Hi, > > I'm using sfsexp in a recent project of mine, and it's really great, > however, I found I little Issue, that I'd like to have fixed: > > new_sexp_atom is prototyped as follows: > > sexp_t *new_sexp_atom(char *buf, int bs); > > I believe that this should look like this: > > sexp_t *new_sexp_atom(const char *buf, int bs); > > Because the buf is only copied, but never touched inside this > function. > > -Richard > > > ------------------------------------------------------- > This SF.Net email is sponsored by Yahoo. > Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > Search APIs Find out how you can build Yahoo! directly into your own > Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg- > q22005 > _______________________________________________ > Sexpr-users mailing list > Sex...@li... > https://lists.sourceforge.net/lists/listinfo/sexpr-users > |
From: Richard S. <ric...@gm...> - 2005-05-28 09:55:26
|
Hi, I'm using sfsexp in a recent project of mine, and it's really great, however, I found I little Issue, that I'd like to have fixed: new_sexp_atom is prototyped as follows: sexp_t *new_sexp_atom(char *buf, int bs); I believe that this should look like this: sexp_t *new_sexp_atom(const char *buf, int bs); Because the buf is only copied, but never touched inside this function. -Richard |
From: <ben...@id...> - 2004-05-25 08:49:49
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
From: MJ S. <mj...@ma...> - 2004-02-23 06:04:16
|
When I was talking about a small subset of Lisp in my last mail I was referring to McCarthy's original operators, which totaled 8 primitives. That is where my love for Lisp started. I don't know another language that can evaluate itself with only 8 operators defined. The list would be something like this. (quote a) returns a, and of course abbreviated as 'a (atom? 'a) returns true if a is an atom or empty list. Otherwise false is returned. (eq? 'a 'b) returns true if the values of a and b are the same atom or both are empty lists. false is returned otherwise. (car x) where x is a list and returns the first element (cdr x) where x is a list and returns everything but the first element These could also be written as destructive operators car! and cdr! in which there is no copy of the list made. (cons x y) where y is a list and returns a list containing the value of x followed by the elements of y (cond (test expr) ... (test2 expr2)) and finally fn should replace the canonical lambda. I agree with Paul Graham, if Alonzo Church had to write lambda for every calculus expression he worked on he would have chosen something different. I am torn as to accomplish the labeling of functions. In my head, binding and identifer to a lambda expression should be accomplished the same way that an identifier is bound to a value with let, and recursively with rlet. But this is where my knowledge is lacking, because there has to be a very good reason for choosing to different operators for defining variables and naming functions. I am just not sure as to what they are. I have also been thinking recently that since, in Lisp, functions and data are treated the same, and are both first class. So my head has been wondering on the area of first class macro's. Once again I am not sure of the implementation problems this may propose, but in my current train of though, macro's are still functions that return data (period, end of story) so why should they be treated any differently. ------------------------------------------------------------------------ -------- M. J. Stahl "I must create a system, or be enslaved by another man's." -- William Blake |
From: matthew s. <mjs...@ma...> - 2004-02-21 21:41:21
|
Hi! I'm not sure how many other people have managed to subscribe to this list since I created it (not too long ago). I'm glad you like the project -- I'm frequently working on it in my free time and it still gets used in quite a few projects at work. Actually, I am due to release a new version soon as I announced last month on the web page. One thing that has been on hold for a little while that I'd still like to finish is a LISP-style interpreter based on this library that supports a very small subset of LISP. If you'd like to hear about what I was thinking about for this I can send along my ideas. Basically, make a very small, fast interpreter for things like arithmetic, lambda expressions, and a few useful intrinsics (like sorting, foldmap, etc...). This could then be embedded in a server that uses s-expressions as it's communication protocol and is connected to other servers in a tree-like fashion. As data passes through the tree, instead of retransmitting the s-expressions, they are manipulated and only the results are transmitted back up -- basically a reduction tree. Another idea I would like to do soon is to connect this library to SML/NJ to convert s-expressions into ML lists. Also, as for RMI and LISP, this is pretty much what the project this parser spun out of does. S-expressions are pushed around the network, parsed, and then manipulated. The only real difference is that instead of executing the s-expressions as LISP, they're treated as data structures for input to existing code. Glad to hear from you. -m On Feb 21, 2004, at 9:50 AM, MJ Stahl wrote: > > Hello everyone. I am new to this project, and in turn to this list, so > I felt that I should introduce myself. > > My name is Mark Stahl, and I am currently attending university in > Savannah, GA. I have a love for languages, and in turn Lisp. > > I wanted to thank you guys for implementing this package because I was > finding many projects that offered more than I needed for my work. > Many of the packages were implementations of large subsets of Scheme > or Common Lisp, and I only wanted the five special forms that John > McCarthy originally developed to bootstrap the first Lisp > implementation. So again my thanks for your efforts in both > minimalism and simplicity. > > I plan on using this library to implement a module Lisp compiler and > interpreter. I understand that many do not wish to program in Lisp > and would prefer to use a more algebraic language like C or Java, but > Lisp makes for a great language to implement other languages on top > of, and of course these new languages (through snarfing the underlying > architecture) have the potential to gain much of Lisp's power. > > The interpreter (virtual machine) will be implemented my like an SECD > machine. But I felt that implementing an interpreter as a monolithic > structure was a bad idea. For example, I wish to do a lot of > experimentation with different language contructs, such as immediate > and lazy evaluation, but I felt that adding both into the language > explicity would lead to an eventual bloat of the standard functions > within the core language. My goal is make the virtual machine, and in > turn the language, modular, much like the dynamic loading of device > drivers in the Linux kernel. > > I also want to extend this idea to remote packages, or remote function > calling. I understand the RMI is nothing new, but Lisp offers a > larger potential when calling remote functions, and that is instead of > returning a value, the source of the function can be returned through > the use of a macro. > > I do apologize that I have babbled on too long, as my excitement has > gotten the best of me. > > Best regards, > > -M. > > ----------------------------------------------------------------------- > --------- > M. J. Stahl > > "I must create a system, or be enslaved by another man's." > -- William Blake > > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > _______________________________________________ > Sexpr-users mailing list > Sex...@li... > https://lists.sourceforge.net/lists/listinfo/sexpr-users |
From: MJ S. <mj...@ma...> - 2004-02-21 17:00:23
|
Hello everyone. I am new to this project, and in turn to this list, so I felt that I should introduce myself. My name is Mark Stahl, and I am currently attending university in Savannah, GA. I have a love for languages, and in turn Lisp. I wanted to thank you guys for implementing this package because I was finding many projects that offered more than I needed for my work. Many of the packages were implementations of large subsets of Scheme or Common Lisp, and I only wanted the five special forms that John McCarthy originally developed to bootstrap the first Lisp implementation. So again my thanks for your efforts in both minimalism and simplicity. I plan on using this library to implement a module Lisp compiler and interpreter. I understand that many do not wish to program in Lisp and would prefer to use a more algebraic language like C or Java, but Lisp makes for a great language to implement other languages on top of, and of course these new languages (through snarfing the underlying architecture) have the potential to gain much of Lisp's power. The interpreter (virtual machine) will be implemented my like an SECD machine. But I felt that implementing an interpreter as a monolithic structure was a bad idea. For example, I wish to do a lot of experimentation with different language contructs, such as immediate and lazy evaluation, but I felt that adding both into the language explicity would lead to an eventual bloat of the standard functions within the core language. My goal is make the virtual machine, and in turn the language, modular, much like the dynamic loading of device drivers in the Linux kernel. I also want to extend this idea to remote packages, or remote function calling. I understand the RMI is nothing new, but Lisp offers a larger potential when calling remote functions, and that is instead of returning a value, the source of the function can be returned through the use of a macro. I do apologize that I have babbled on too long, as my excitement has gotten the best of me. Best regards, -M. ------------------------------------------------------------------------ -------- M. J. Stahl "I must create a system, or be enslaved by another man's." -- William Blake |