May 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] SimpleLiteralArrayParser

by H. Hirzel

Hi StÃ©phane Goran writes here http://goran.krampe.se/2012/05/08/literal-arrays-vs-json-vs-ston-vs-tirade/ <citation> Literal Smalltalk arrays The simplest notation of all in the lineup is the literal array syntax in Smalltalk. The example below covers all its capabilities AFAIK (in Pharo/Squeak), please tell me if I missed anything: #(4711 3.4 16r3F 'string' #symbol #'another-symbol' (nested array) #(one more) true false nil $x #[12 32]) </citation> Do you agree that this covers everything in terms of literal arrays? --Hannes On 4/24/12, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Mariano > > read the metacello mailing list mails I sent. I hate hate hate repeating > myself. > > I started to work on the LIteralArrayParser so that we do not have the > problem in the future. > > Stef > > On Apr 24, 2012, at 12:52 PM, Mariano Martinez Peck wrote: > >> >> >> On Tue, Apr 24, 2012 at 12:43 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >> > Hi guys >> > >> > We should develop a simple Literal Array parser that is dialect >> > independant >> > so that we can avoid using JSON for meta data. So I will start to >> > develop. I will start to write some tests and do it test first. >> > >> > Gofer new >> > repository: 'http://ss3.gemstone.com/ss/SimpleLiteralArrayParser'; >> > package: 'SimpleLiteralArrayParser'; >> > load >> > >> > Now I still wonder what do we do about floats. May be the situation >> > changed but Squeak and VW floats were not the same. >> > >> > I don't get it. You define your own float format, and then each dialect >> > parses it and converts it to their correspondant format... Now, I do >> > not know the format >> > differences so I do not know which one take :). >> >> It can work for simple scenario but if you save a float with e120 and save >> it and you get e70 >> then you are in trouble. >> >> You are not in trouble. And if you are, then you are exactlty the same as >> if you were using a literal parser. >> You have a specification. You say that floats are written in THIS XXX text >> representation. Nobody cares how your floats are represented inside your >> Smalltalk. For JSON you write floats in a particular way, explained by the >> JSON specification. >> Then, when you code the parser, you will need to crate an instance of >> Float from the string. Each dialect will know how to do that. >> So, again, where is the problem? >> And how the literal parser would solve it? because I think it will >> happen the same. >> >> Cheers, >> >> >> >> Stef >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > >

May 10, 2012

Re: [Pharo-project] [squeak-dev] Re: A comparative article (was STON - Smalltalk Object Notation)

by H. Hirzel

Hello A question about dynamic arrays Goran writes that he thinks they were introduced in Squeak? Is this correct? If yes when? References? Which other Smalltalk dialects do have them? Regards Hannes On 5/8/12, Janko MivÅ¡ek <janko.mivsek(a)eranova.si> wrote: [...snip] > > Dne 08. 05. 2012 09:55, piÅ¡e GÃ¶ran Krampe: >> Hi guys! >> >> I just posted an article about JSON/STON/Literal arrays/Tirade - and it >> is probably easiest to read at planet.smalltalk.org (my blog has a >> rather bad theme I realized): >> >> http://planet.smalltalk.org >> >> ...or at my blog: >> >> http://goran.krampe.se/2012/05/08/literal-arrays-vs-json-vs-ston-vs-tirade >> >> Sven - sorry for beating down a bit on STON in that article, nothing >> personal and I love all the stuff you have done, I just have a hard time >> placing STON in my toolbox. If you can give me good arguments why I am >> dead wrong - please do! ;) >> >> And regarding Tirade, feel free to criticize that too of course, it is >> still not set in stone and all input is appreciated, including telling >> me it sucks :). >> >> The most interesting bit of the article is perhaps my thoughts on >> literals in Smalltalk - would be nice to hear what people thiná¸±. And oh, >> sorry for the length of the article - it kinda swelled. >> >> regards, GÃ¶ran

May 10, 2012

Re: [Pharo-project] Redirecting Transcript

by Sean P. DeNigris

The thread title should've been "Headless Output" (although that doesn't really capture it either bc OS X headless doesn't seem to work)... I'm starting to put all my projects into Jenkins and want more feedback in the console output. So, I also want to catch all the progress bar titles and send them to stdout. I experimented with catching them thusly: FileStream fileNamed: 'loadLog.log' do: [ :str | [ConfigurationOfAutotest project bleedingEdge load] on: ProgressNotification, ProgressInitiationException do: [ :e | str nextPutAll: e asString; cr. e pass ] ]. which was weird... it caught all the top-level messages, but not the sub ones (e.g. while doing 'Loading 1.0-baseline of ConfigurationOfAutotest' (which was logged by the above), the 'Loading Autotest-Core' subtask was not logged. I stepped through and debugged for a while, but couldn't see the problem... Sean -- View this message in context: http://forum.world.st/Redirecting-Transcript-tp4622373p4622408.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 10, 2012

[Pharo-project] Redirecting Transcript

by Sean P. DeNigris

There were several list threads about redirecting the Transcript e.g. to stdout... Is this available now in Pharo? If so, how do I redirect it to stdout? Thanks. Sean -- View this message in context: http://forum.world.st/Redirecting-Transcript-tp4622373.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 10, 2012

Re: [Pharo-project] [Vm-dev] Re: Can OSProcess functionality be implemented using FFI instead of plugin?

by Nicolas Cellier

2012/5/8 Igor Stasenko <siguctua(a)gmail.com>: > On 7 May 2012 20:15, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> >> >> On Sun, May 6, 2012 at 9:14 AM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> >>> 2012/5/6 Igor Stasenko <siguctua(a)gmail.com>: >>> > On 6 May 2012 17:08, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> >> 2012/5/6 Guillermo Polito <guillermopolito(a)gmail.com>: >>> >>> >>> >>> >>> >>> On Sun, May 6, 2012 at 2:16 PM, Esteban Lorenzano <estebanlm(a)gmail.com> >>> >>> wrote: >>> >>>> >>> >>>> <snip> >>> >>>> I'm more worried about having all-platforms-specific-stuff inside image... >>> >>>> but we can mitigate that with fuel, and making loadable packages when >>> >>>> running the image... I don't know, I'm just thinking while writing, so, this >>> >>>> is probably stupid :) >>> >>>> >>> >>> >>> >>> Just think how many times you took a development image and used it in >>> >>> several platforms.Â At least I don't.Â Same happened when I used Eclipse.Â I >>> >>> didn't share my eclipses between systems.Â Even, I had several eclipse >>> >>> installations with their own plugins (just like images, hehe). >>> >>> >>> >>> Probably with jenkins, metacello, and kernel/bootstrap we can generate >>> >>> distributions per platform (With the possibility of an all-in-one >>> >>> distribution for the ones who like that). >>> >>> >>> >>> Guille >>> >> >>> >> Yes, I understand that we can live without this feature... >>> >> - If we can reconstruct images easily (one of the goal of Pharo) - I >>> >> mean not only code, but any object (eventually with Fuel) >>> >> - If we solve the bootstrap problem (or if we can still prepare an >>> >> image for cross platform startup) >>> >> - If we don't forget to always talk (send messages) thru an abstract >>> >> layer, and never directly name the target library, >>> >> >>> >> Since I didn't have all these tools in the past, I were forced to use >>> >> development images across different platform a lot, and yes, it was >>> >> not following the mainstream rules (a la "we can reconstruct all from >>> >> scratch") but damn powerful. >>> >> For deploying applications, it also is very powerful and cheap. >>> >> Personally, I would feel sore to lose it. >>> >> >>> > >>> > But look at the root of what we are talking about: N bytes in VM >>> > versus M bytes in image to support certain functionality. >>> > I think if you need it, you will make sure that those bytes is there >>> > and properly packaged with you application. >>> > >>> >>> Unfortunately, it's more than moving code... >>> What I mean is that when I need to pass an O_NONBLOCK flag to a FFI >>> call, it's going to be a problem because I have to know how this >>> information is encoded on each and every platform I want to support. >> >> >> But there are solutions to this which mean you *don't* have to know. Â I wrote a prototype for VisualWorks that maps a SharedPool to these externally defined variables. Â Here's how it works. >> >> For each group of C constants, e.g. i/o constants, one populates a subclasss of SharedPoolForC with the variables one wants to define, and in a class-side method one defines the set of include files per platform that one should pull in to evaluate the constants. Â SharedPoolForC has code in it to automatically generate a C program, and compile it, e.g. to provide a shared library/dll for the current platform. Â The C program is essentially a name-value dictionary that maps from the abstract name #O_NONBLOCK to the size and value for a particular platform. Â SharedPoolForC also contains code to load the shared library/dll, extract the values and update the pool variables automatically. >> >> The deployment scheme is as follows, at start-up the system asks each SharedPoolForC subclass to check the platform and see if the platform has changed. Â If it hasn't changed, nothing needs to happen. Â If it has changed the system attempts to locate the shared library/dll for the current platform (the platform name is embedded in the dll's name), and update the pool variables from that dll, raising an exception if unavailable (and the exception could be mapped into a warning or an error to suit). Â So to deploy e.g. a one-click one needs to generate the set of dlls fort the platforms one wants to deploy on. >> >> The development scheme is simply to run a method on the SharedPoolForC when one adds some class variables and/or changes the set of include files which turns the crank, generating, compiling and loading the C file to get the value(s) for the new variable(s). >> > Having an in-image C-parser is a pain (VW/DLLCC parser is not maintained and cannot parse modern headers). So I agree, the best is to use an external C preprocessor/compiler, it's up to date. We thus replace C with C, so it seems more or less equivalent... Is it? We mirror these defines in image with a bunch of OSAPI subclasses. We have also to handle different structure layout if some or our API functions are picking-fields-macros... Also across several linux distros, one has glibc 4.5 and libm 4.8, the other glibc 5.1 but libm 4.3, plus opengl, ssl, etc... A lot of combinatorial... So we cleverly decide to reify each library, and subclass them with each major version, so as to program an OSAPI by composition. We then just have to prepare a configuration file. And if we are very clever, maybe we can query the OS and create a sort of autoconf... To ease our task, each OS provides more or less the same functions, but these are not packaged the same. Two functions are in same library in this OS, and two different libraries on another. Or we have several concurrent implementations (like winsock wsock2)... Some of these nice features of the real world are also polluting the C code of our plugins with #ifdef #include and platform dependent files, but some of the concerns are separated in makefiles at compile time and mainstream cmake and other shits help us a bit. In FFI, I still have the feeling that it is worse simply because we have to resolve the macros and care for differences that would not appear in our C source (only in machine dependent includes), and also care for library packaging if we want to use composition... It's not that it's not doable, it's that we gonna reinvent gaz plant and it gonna be so boring... I'd like to see a proof of concept, even if we restrict to libc, libm, kernel.dll, msvcrt.dll ... Bonus, imagine I install a brand new Linux v3.x.x Because we have a simpler VM, and they care of compatibility, I can recompile the VM, the plugins and restart my favourite image with reduced cmake activity. Unfortunately files are not accessed via a plugin but via FFI, the FILE structure layout changed, I used a picking-fields-macro (like getc, feof, FD_SET or ...) and my image crashes at startup... I have to extract the new structure/defines on v3.x.x, restart an old kernel v2.y.y, prepare in-image structure for new OS, save the image, restart kernel v3.x.x. Phew... I ain't got the feeling we simplified the tool chain in this case too. Nicolas > Yes, i remember you told about it some years ago ;) > > But this requires a platform with compiler installed. otherwise your > system won't be able to adopt to new environment. But of course there > is a solution to that as well: keep a database for every platform in > image, > and detect platform on startup, hoping that everything is in sync :) > And if not, then it usually means that guy using either non-standard > distribution, or custom built kernel etc.. At this point i would stop > worrying about it, since if he is good enough to be able to customize > own system, he can deal with FFI troubles in no time.. > and usually those guys having compiler installed :) > > Also, Â if system supports binary distributions, then we're in same boat > as any other binary compiled and distributed for that platform.. (need > to elaborate that?) > >> An alternative scheme would generate a program that would print e.g. STON, which could be parsed or evaluated to compute the values. Â This would have the advantage that the definitions of the values are readable and editable by mere humans. Â So I think I'd discard the shared library/dll approach and keep it simple. >> >> > Indeed. Again, generate C code.. a bit more code doesn't hurts. > > > -- > Best regards, > Igor Stasenko. >

May 9, 2012

Re: [Pharo-project] FFI in Fedora

by Casimiro de Almeida Barreto

On 09-05-2012 19:25, Schwab,Wilhelm K wrote: > Even on Ubuntu, the library search is broken. I've had to create > symlinks in the vm directory to get Cog to see much of anything. Are > you using callbacks? I tried them, with some success, but ultimately > went back to using a C/C++ .so to export needed functions. The > callbacks were "working" and I could step through them with the > debugger ( very encouraging and useful!!!!), but ultimately I would > get one of a couple of downstream errors after the callback activity > was over, or so it seemed. > > Is your image crashing as part of this? > > > > ------------------------------------------------------------------------ > *I tried both ways with native (pre-compiled VMs) and VMs that I compiled myself. Native CogVM fails but won't crash. The same with native SqueakVM (traditional VM). CogVM won't compile 64bit mode. SqueakVM compiles 64bit mode and then is capable of calling /usr/lib64 stuff. But most stuff will crash due to problems with pointer sizes. I've got crashes like: *bash-4.2$ LD_LIBRARY_PATH=/usr/lib/nvidia:/usr/lib:$LD_LIBRARY_PATH export LD_LIBRARY_PATH bash-4.2$ /usr/local/lib/squeak/*/squeakvm Segmentation fault 36490628 OpenGL>beginFrame 36490536 OGLUnixX11LE>beginFrame 36488076 OpenGL class>example 36487984 BlockClosure>ensure: 36418764 OpenGL class>example 36418672 UndefinedObject>? 35844976 Compiler>evaluate:in:to:notifying:ifFail:logged: 35846456 TextEditor>evaluateSelectionAndDo: 35846364 BlockClosure>on:do: 35846272 TextEditor>evaluateSelectionAndDo: 35846180 TextEditor>evaluateSelection 35846088 PluggableTextMorph>doIt 35845952 TextMorph>handleEdit: 35845736 PluggableTextMorph>handleEdit: 35845644 PluggableTextMorph>doIt 35845528 StringHolder>perform:orSendTo: 35845412 MenuItemMorph>invokeWithEvent: 35845320 BlockClosure>ensure: 35845228 Cursor>showWhile: 35844776 MenuItemMorph>invokeWithEvent: 35844684 MenuItemMorph>mouseUp: 35844592 MenuItemMorph>handleMouseUp: 35844460 MouseButtonEvent>sentTo: 35844368 Morph>handleEvent: 35844276 MorphicEventDispatcher>dispatchDefault:with: 35844184 MorphicEventDispatcher>dispatchEvent:with: 35844092 Morph>processEvent:using: 35844000 MorphicEventDispatcher>dispatchDefault:with: 35843892 MorphicEventDispatcher>dispatchEvent:with: 35843760 Morph>processEvent:using: 35843668 Morph>processEvent: 35843576 MenuMorph>handleFocusEvent: 35843484 HandMorph>sendFocusEvent:to:clear: 35843328 BlockClosure>on:do: 35843236 PasteUpMorph>becomeActiveDuring: 35843116 HandMorph>sendFocusEvent:to:clear: 35843024 HandMorph>sendEvent:focus:clear: 35842932 HandMorph>sendMouseEvent: 35842788 HandMorph>handleEvent: 35842444 HandMorph>processEvents 35842352 WorldState>doOneCycleNowFor: 35842260 SequenceableCollection>do: 35842168 WorldState>handsDo: 35842076 WorldState>doOneCycleNowFor: 35841892 WorldState>doOneCycleFor: 35841800 WorldState>doOneSubCycleFor: 35841708 PasteUpMorph>doOneSubCycle 35821636 MenuMorph>invokeModalAt:in:allowKeyboard: 35821544 MenuMorph>invokeModal: 35821440 MenuMorph>invokeModal 35814024 PluggableTextMorph>yellowButtonActivity: 35813932 ScrollPane>mouseDown: 35813840 Morph>handleMouseDown: 35813748 MouseButtonEvent>sentTo: 35813656 Morph>handleEvent: 35813484 MorphicEventDispatcher>dispatchMouseDown:with: 35813392 MorphicEventDispatcher>dispatchEvent:with: 35813300 Morph>processEvent:using: 35813168 MorphicEventDispatcher>dispatchMouseDown:with: 35813076 MorphicEventDispatcher>dispatchEvent:with: 35812984 Morph>processEvent:using: 35812892 MorphicEventDispatcher>dispatchMouseDown:with: 35812800 MorphicEventDispatcher>dispatchEvent:with: 35812692 Morph>processEvent:using: 35812600 PasteUpMorph>processEvent:using: 35812488 Morph>processEvent: 35812396 HandMorph>sendEvent:focus:clear: 35812304 HandMorph>sendMouseEvent: 35812160 HandMorph>handleEvent: 35812000 HandMorph>processEvents 35811908 WorldState>doOneCycleNowFor: 35811816 SequenceableCollection>do: 35811724 WorldState>handsDo: 35811632 WorldState>doOneCycleNowFor: 35811540 WorldState>doOneCycleFor: 35811448 PasteUpMorph>doOneCycle 31204620 Project class>spawnNewProcess 31201020 BlockClosure>newProcess* But it was expected since it was a 64bit VM pointing to 32bit libraries... When LD_LIBRARY_PATH is left unchanged, then it won't crash and it won't load libraries. *

May 9, 2012

Re: [Pharo-project] Strangest object ever seen?

by Francisco Garau

It also happened on a 20032 image (see screenshot). Smalltalk cleanUp didn't solve the issue here. Please, note the Unnamed Changeset with a Dictionary... - Francisco On 9 May 2012 20:27, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > On Wed, May 9, 2012 at 3:39 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: > >>> Now I do not understand why this guy cannot get printed. > >>> > >>> I do not see why > >>> > >>> ClassDescription>>printOn: aStream > >>> aStream nextPutAll: self name > >>> > >>> Metaclass>>name > >>> "Answer a String that is the name of the receiver, either > 'Metaclass' or > >>> the name of the receiver's class followed by ' class'." > >>> > >>> thisClass == nil > >>> ifTrue: [^'a Metaclass'] > >>> ifFalse: [^thisClass name , ' class'] > >>> > >>> self first soleInstance printString > >>> -> leads to have emergency debugger. > > > > you do not get emergency! > > I do not like when we do not get the same bugsâ¦ > > on some inst vars and expressions I get the emergency evaluator. > > > > > > >> self name shows: > >> > >> a Dictionary(#DependentsFields->a WeakIdentityKeyDictionary(a > >> CategoryWidget->a DependentsArray(a PluggableIconListMorph(217841664)) > >> a ContextVariablesInspector->a DependentsArray(a > >> PluggableListMorph(445382656) a PluggableTextMorph(1046216704)) a > >> ContextVariablesInspector->a DependentsArray(a > >> PluggableListMorph(290193408) ... ) > >> > >> The source of printing problems will be in thisClass. > >> > >> The next interesting thing is that it has no pointers and it is > >> removed after garbageCollect. > > > > So this is a good news :). > > The question is what produced such strange object and how many similar > ones we still have in the image. It can have very unwelcome > consequences - for example the segmentation faults on Fuel packages > exports when executed from command line. But from workspace it behaves > differently. > > -- Pavel > > > > >> > >> -- Pavel > >> > >> > >> > >> > >>> Stef > >>> > >>> > >>> > >>> > >>> > >> > > > > > >

May 9, 2012

[Pharo-project] Short rant on platforms and sessions

by Schwab,Wilhelm K

I've been unable to follow the whole list lately, but I caught some mention of what might be a more toward platform-dependence, or lack of independence. I *like* being able to work on Linux and deploy to Windows. Hopefully we won't lose that. I agree that things should happen in the image far more than in the vm - easier to see and fix. The Smalltalk debugger is great, so we should use it at every opportunity; putting things in the image is enabling. Dolphin shows us the correct path: session awareness. The image "wakes up" and decides where it is running - the vm can certainly help in Pharo's case. External resources are *not* cleared on image save - the image might keep running, so why release and reallocate? Finalization is best-effort. External resources are cleared just before exiting, but *after* any associated image save. When the image wakes, one of its first duties is to clear (not release via calls) any external resources, because they are known to be garbage at this point. It works, and works well. Bill

May 9, 2012

Re: [Pharo-project] FileList efficiency could hardly be worse

by Schwab,Wilhelm K

This is one of those things that I find shocking. Squeak has been around for 15+ years, and still has no efficient way to get files matching a wildcard pattern (I sure couldn't find it), FFI does not (easily) support callbacks, etc. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Nicolas Cellier [nicolas.cellier.aka.nice(a)gmail.com] Sent: Wednesday, May 09, 2012 6:18 PM To: Pharo Development Subject: [Pharo-project] FileList efficiency could hardly be worse The efficiency of FileList>>listForPattern: is something which should deserve a bit more care. It tries to sort the files, for example by name, but wants to display directory first ^ [ :x :y | |xIsDir| ((xIsDir := x isDirectory) = y isDirectory) ifTrue: [ x basename <= y basename ] ifFalse: [ "directories always precede files" xIsDir ]] Alas, this isDirectory test cost you an arm: FileReference>>isDirectory ^ filesystem isDirectory: path FileSystem>>isDirectory: aResolvable "Resolve the argument, and answer true if the result refers to a directory, false if it refers to a file or doesn't exist." ^ store isDirectory: (self resolve: aResolvable) FileSystemStore>>isDirectory: aPath aPath isRoot ifTrue: [ ^ true ]. self nodeAt: aPath ifPresent: [ :entry | ^ self basicIsDirectory: entry ] ifAbsent: [ ^ false ]. DiskStore>>nodeAt: aPath ifPresent: presentBlock ifAbsent: absentBlock | name| aPath isRoot ifTrue: [ ^ presentBlock value: self rootNode ]. "| encodedPath encodedBasename entry | encodedPath := Primitives encode: (self stringFromPath: aPath parent). encodedBasename := Primitives encode: aPath basename. entry := Primitives lookupDirectory: encodedPath filename: encodedBasename. ^ entry == #badDirectoryPath ifTrue: absentBlock ifFalse: [ entry at: 1 put: aPath basename. presentBlock value: entry ]." name := aPath basename. self directoryAt: aPath parent ifAbsent: absentBlock nodesDo: [ :entry | (self filename: (entry at: 1) matches: name) ifTrue: [ ^ presentBlock value: entry ] ]. ^ absentBlock value Arghh, it scans the whole parent directory again! If sort is O(n log n), then we transform it into O(2 n^2 log n). Try to browse your package-cache if you're not a chicken. Seriously, it's unusable... Nicolas

May 9, 2012

Re: [Pharo-project] Help reading dump?

by Schwab,Wilhelm K

Eliot, Replacing the Smalltalk code with C would be daunting task. I had a similar idea, which was to write something that does the iteration in one function. That would be more manageable, but when faced with the reality of doing even that, I was reminded that one scenario worked perfectly, and one was giving goofy results. The latter might have been an illconditioned model. A slightly simpler model fits the data without "getting itself in a twist." Some additional diagnostic output will show me what happened just before a segment fault. It's possible that I'm accessing some undefined state after a failed iteration, or something equally silly. Still, I think the segment faults are overkill/suspicious. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Eliot Miranda [eliot.miranda(a)gmail.com] Sent: Wednesday, May 09, 2012 11:58 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Help reading dump? On Wed, May 9, 2012 at 8:16 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: The attached is diagnostic output from the Linux vm. I am doing some iterative numerical analysis that won't always work out, so I expect errors and non-sense results at times - it all depends on whether a particular segment of a signal is clean or noisy; if the latter, all assumptions are off. One thought is that early terminated iterations (or maybe ones that go too long?) are leaving conditions that finalization can't clean, or maybe does not clean before the next iteration begins. A segmentation fault seems a bit harsh, but they are happening and I need to find a way around them. Is there anything in the attached dump that strikes you as significant? Maybe something that says whether its the main thread or a background thread that's blowing up, or some other clue that is obvious to the correct eye? As it is, I see the #iterate, #basicIterate part of the stack, which is what I would expect the code to be trying to do - fit curves to data. The numbers at the beginning are trace info (using C++ cout) to confirm sanity of the arriving parameters. My next thought is to add some more tracing to show which segment/harmonic is being attacked as it blows up. Then I might be able to set clever breakpoints and get some handle on it. Suggestions are welcome. Put instrumentation around the calls that allow you to write a C program that makes the exact same calls and see if that crashes? Bill -- best, Eliot

May 9, 2012