- Pharo-dev - lists.pharo.org

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

[Pharo-project] FileList efficiency could hardly be worse

by Nicolas Cellier

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] FFI in Fedora

by Casimiro de Almeida Barreto

On 09-05-2012 16:17, Adriel Paredes wrote: > I have the 32 bits libraries... It works in ubuntu, but not in fedora This stuff of FFI has been discussed in the VM-dev list. Making FFI work in linux x86_64 is a real pain. First, CogVM as it comes with Pharo distribution or as you get from Eliot's repositories are 32bits. Then you have to have all 32bit libraries installed <and> LD_LIBRARY_PATH adjusted to point first to the /usr/lib instead of /usr/lib64. But even so, things just don't work plainly. I am having trouble with OpenGL, Fann and some other libraries. Also, currently FFI doesn't support 64bit binaries. CdAB > > On Wed, May 9, 2012 at 4:15 PM, Milan Mimica <milan.mimica(a)gmail.com > <mailto:milan.mimica@gmail.com>> wrote: > > Does FFI even support 64-bit binaries? > > > On 9 May 2012 20:42, Adriel Paredes <adriel.paredes(a)gmail.com > <mailto:adriel.paredes@gmail.com>> wrote: > > Hi Folks... > > I'm having some troubles with FFI in Fedora x86_64. I tried to > execute some OS functions. I have all the libreries needed for > that, but I always have the same error. In the *stack top > *into FFICallbackThunk class when I send the > allocateExcecutablePage message i got this: *#'insufficient C > memory' * > > Has anyone had this kind of error before? > > > This is the stack trace in my terminal. > > PrimitiveFailed: primitive #allocateExecutablePage in > FFICallbackThunk class failed > FFICallbackThunk class(Object)>>primitiveFailed: > FFICallbackThunk class(Object)>>primitiveFailed > FFICallbackThunk class>>allocateExecutablePage > FFICallbackThunk class>>unusedBlockInExecutablePage in Block: > [ExecutablePages add: self allocateExecutablePage]...etc... > Semaphore>>critical: in Block: [caught := true.... > BlockClosure>>ensure: > Semaphore>>critical: > FFICallbackThunk class>>unusedBlockInExecutablePage > FFICallbackThunk class>>privateFinalizingNew > FFICallbackThunk class>>newCCall > > > -- > Adriel Paredes > E-Mail: adriel.paredes(a)gmail.com > <mailto:adriel.paredes@gmail.com> > Twitter: @adrielparedes > Skype: adriel.paredes > > > > > > -- > Milan Mimica > http://sparklet.sf.net > > > > > -- > Adriel Paredes > E-Mail: adriel.paredes(a)gmail.com <mailto:adriel.paredes@gmail.com> > Twitter: @adrielparedes > Skype: adriel.paredes > >

May 9, 2012

Re: [Pharo-project] tentative schedule for the pharo conference

by Francisco Garau

Hi Stef - there is one hour difference between the iCal and HTML versions. It starts at 9am, correct? - Francisco On 9 May 2012 12:20, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > Hi guys > > Here is a tentative schedule for the forth coming conference. > > ICAL: > > https://www.google.com/calendar/ical/2d97rjlqso704v09d49sgcsjec%40group.cal… > > HTML: > > https://www.google.com/calendar/embed?src=2d97rjlqso704v09d49sgcsjec%40grou… > > > please lets us know if you have any idea feedback. > -- > > Sef >

May 9, 2012

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

by Pavel Krivanek

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