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

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

by StÃ©phane Ducasse

> Hi, > > If you take the latest Pharo 2.0 image from Jenkins (20059) and you execute the expression: > > (Metaclass allInstances select: [:c | c superclass = ProtoObject class]) inspect > > you will get an collection inspector where the first object is very strange one. It is very hard to get any useful information about the origin of this evil object. The only thing we know exactly is that it causes virtual machine segmentation faults while trying to export class ScrollBar via Fuel. Not only CogVM but even StackVM. > > Can you, please, try to help us to get as much information as possible about this object? I named it "dzindzik" :-) > > Cheers, > -- Pavel In 20060 I got 4 elements and the first one is apparently Metaclass but I do not understand why self first class Metaclass self first class superclass ClassDescription 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. Stef

May 9, 2012

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

by StÃ©phane Ducasse

>> >> Parsing and compiling + execution are three different actions. >> Parsing: stream -> tokens* but you know it. > > Of course. What I mean is that depending on how you "parse" a Smalltalk literal you may or may not be susceptible to a security hole. If you just blindly use the full Compiler to do the whole thing - then you have a hole. If you do not, then you don't. Igor showed a neat way to only use the literal array part of the parser - fine, no hole. But if you just use full Compiler - not fine. yes so using literal array does not bring any security problems. Or we should say stupidly using the compiler introduces security problems and so far I never advocate for that. > [SNIP] >>> My point is that it would be nice if we actually had proper syntax for Associations (and or Dictionaries). >> >> OK I see. But what I want to say is that then this is not a literal array anymore. >> Literal means that you only need a parser and no execution to get the information. Parse time. > > But Stephane... please *read* what I write in the article. Let me repeat: > > #-> is a message in Smalltalk, not a literal syntax. Not in my compiler :) > We all know that. > > BUT... there is nothing preventing us from adding support in the Smalltalk parser to handle this as a *literal* syntax that creates an Association. and what else? So people want ANSI compatibility and at the same time new syntax > Tirade has support for it and a large part of the article talks about this, but I presume you have not read it. > >> Now I would like to know the use case for a dictionary syntax or association. > > There are TONS of use cases. The whole success behind JSON is IMHO based on the fact that it has explicit syntax for *both* arrays and dictionaries (called "objects" in JavaScript). Nested structures of these two building blocks is a very potent combination. And Smalltalk literal arrays only give us ONE of them. Not only arrays and dictionaries. Just plain objects and this is a key difference!!!!! Dictionaries are not objects in Smalltalk so adding dictionary looks to me like a patch. > >> May be you mean that you want to have the equivalent of { } but for dictionary, why not. > > Sigh. "Maybe"? Ok, things would be MUCH simpler if you actually read the article you know. And no, not really, because {} is a *dynamic* array with expressions in it and I am talking about (primarily) *literal* dictionaries. ok I was talking about the syntactic aspect of having { } instead of writing Array new: because this is what you want {|% instead of Dictionary newFrom: >> Having a syntax for a syntax is not really exciting. > > What? > >> Now I think that the key problem is dealing with reference between >> elements. for that STON can be better because why stopping at dictionary? But then the next question if we go down this >> road is why don't we add this syntax to smalltalk so that we can create literals objects like in Javascript. >> I mean without message send because this is exactly that no? >> What is the difference between >> Dictionary new add: #flop put: 33 ;yourself >> and >> {|% flop : 33 %|} >> >> or Person { >> name : 'stef' >> } > > The difference? Well, the first is an imperative Smalltalk program (fully insecure of course since I presume you would parse and execute it as full Smalltalk) and the second two are declarative literal syntaxes that are safe to parse. You could also say quite limited because you can only put dictionary inside dictionary and literals. so no objects. but in that case why don't we use literal syntax for objects? Why stopping at Dictionary. If you ask me I would remove #() as a syntactic elements because most of the time { } is what you want. >> then this is not really Smalltalk anymore and we cannot say that we only have messages and the parser and â¦. >> have to be changedâ¦. This is why I asked what is the use case. > > Your reasoning is very... confusing. What do you mean "only have messages" - we *already* have a whole bunch of literal syntax for creating objects. What makes a Dictionary so special compared to Arrays? so Dictionary and Set and why not objectsâ¦. > > And "not really Smalltalk anymore"... ehm, I give up. > > Anyway, my article mainly says that Smalltalk literals go a long way BUT without the support for Dictionaries they fall short of JSON, and that is a bit of a shame I think. But still - the article was mainly food for thought - I am not fighting a battle here, I am just exploring. > >> Finally and I still did not get a clear answer: why there is a need for dictionary syntax to store method meta data. > > Can you please stop referring to "method meta data" all the time? This thread is about an article I wrote that you haven't read and it has nothing to do with that use case. Ok? Because I do not care if you want to use STON, JSON XML for your own program this is your choice. I care that I will have to load JSON, STON in core to load or save code and that I have to use a different syntax to look at code in Git. > > regards, GÃ¶ran

May 9, 2012

Re: [Pharo-project] smallUML news: towards autogenerated diagrams

by StÃ©phane Ducasse

Hi carla why do you need to pass a block? > > > You will notice that what I've got so far is: > â¢ Drawing the classes involved in the evaluation of that block, with the messages that were sent during that block > â¢ Drawing the superclasses involved along with the inheritance arrow. Superclasses are included only if there are inherited methods excecuted. > â¢ Drawing the association relationships between instances! That's my favorite part, and the one that was not trivial to achieve. The code still sucks, but it's working. You can see that the association relationships between the Ship, the Pirate and the Mission are drawn, and Collections are 'skipped' as in a regular class diagram using the cardinality annotation * over the arrow. > What's interesting about this last point, is resolving these (still pending) issues: > â¢ If an object form class A has a collection where the elements are of different classes, or if it has an attribute that could point to different polimorfic objects, there should be just one association arrow from class A to: > â¢ the superclass of those different classes, or > â¢ the inferred type those different classes share: this comes along with some questions, like 'what will the type name be?' > â¢ What will be the scope of the diagram? Objects can have attributes ponting to numbers, strings, blocks, booleans, etc. Are we interested in showing those classes in a class diagram? usually it does not really work to display primitive types using arrow a type annotation of the instance variable would be enough. A design diagram is usually focusing on relation between domain entities > I guess, it depends. The diagram scope should not be hard coded (as it is now :P), because if we want to document a core package, some core classes will have to appear instead of being ignored like we would prefere in a 'domain specific' diagram. > â¢ Collections are 'skipped' in the diagrams. That means that if an object A points to a collection, that points to several objects of class B, in the diagram only the classes A and B are shown with the classical 'one to many' arrow. This will mess up diagrams of the collection packages themselves :P > So, I invite you to think about how could these issues be resolved, and also play a little bit with what I've got so far, executing [your block code] asClassDiagram openQuickView. > > I hope that the GSoC project of Santiago will help with the type inferences part :) but if you do a dynamic analysis then you already get the concrete type of objects so you will not gain much more. Can you show us the way nodes are created? I mean that is the model because what I would like is a class and relations model that we can navigate to draw morphic or other objects. Stef > > Cheers! > Carla. > >

May 9, 2012

Re: [Pharo-project] [squeak-dev] Re: [ANN] STON - Smalltalk Object Notation

by H. Hirzel

On 5/5/12, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > Hi Hannes, > > On 05 May 2012, at 11:53, H. Hirzel wrote: > >> Thank you Sven for your follow up of the recent JSON/STON/Tirade >> discussion by providing an STON implementation for Squeak 4.3 and >> working with Dale to get it to other Smalltalks (github). [1] >> >> I think your STON implementation will be very useful for my work. It >> works fine in Squeak 4.3 updated to the latest change [2]. > > Thanks for the feedback and the encouragement. > >> There is a class STON used as a singleton. I assume this is the >> equivalent of the JSON object in web browsers, right? > > I am afraid I am not familiar enough with how JSON is handled in > Javascript/Webbrowsers, so I cannot compare. > > But the STON object in the current implementation is a class facade API to > read/write to/from streams/strings while hiding the actual parser or writer > classes. It is a central access point, but it is very thin: using STONReader > or STONWriter directly is perfectly OK too. Maybe I should add some > invocation examples to the paper to explain the API. > > Sven Hi again, Sven, Thank you for this explanation and the updating of the documentation on github. For the JSON object in web browsers ECMAScript 5.1 specification: chapter 15.12 <citation> The JSON object is a single object that contains two functions, parse and stringify, that are used to parse and construct JSON texts. The JSON Data Interchange Format is described in RFC 4627 <http://www.ietf.org/rfc/rfc4627.txt>. </citation> And https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/JSON Regards Hannes

May 9, 2012

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

by H. Hirzel

On 5/9/12, GÃ¶ran Krampe <goran(a)krampe.se> wrote: > Hi all! > > First - I am not fighting nor pushing in any direction. I just find the > subject interesting. > > On 05/08/2012 10:59 PM, StÃ©phane Ducasse wrote: >>>> :) there is no security problem just that gemstone does not have a >>>> parser. Because parsing cannot be a security hole >>>> this is blind data interpretation that is a problem. This is why Github >>>> got problems and I imagine that the code was probably passed in JSON or >>>> similar format. >>> >>> Mmm, well, if you rely on full Compiler to parse literals, it is a >>> security problem. But if you use the technique Igor showed to only parse >>> array literals - then yes, that's safe, I agree. I forgot about his >>> post. >> >> Parsing and compiling + execution are three different actions. >> Parsing: stream -> tokens* but you know it. > > Of course. What I mean is that depending on how you "parse" a Smalltalk > literal you may or may not be susceptible to a security hole. If you > just blindly use the full Compiler to do the whole thing - then you have > a hole. If you do not, then you don't. Igor showed a neat way to only > use the literal array part of the parser - fine, no hole. But if you > just use full Compiler - not fine. > > > [SNIP] >>> My point is that it would be nice if we actually had proper syntax for >>> Associations (and or Dictionaries). >> >> OK I see. But what I want to say is that then this is not a literal array >> anymore. >> Literal means that you only need a parser and no execution to get the >> information. Parse time. > > But Stephane... please *read* what I write in the article. Let me repeat: > > #-> is a message in Smalltalk, not a literal syntax. We all know that. > > BUT... there is nothing preventing us from adding support in the > Smalltalk parser to handle this as a *literal* syntax that creates an > Association. Tirade has support for it and a large part of the article > talks about this, but I presume you have not read it. > >> Now I would like to know the use case for a dictionary syntax or >> association. > > There are TONS of use cases. The whole success behind JSON is IMHO based > on the fact that it has explicit syntax for *both* arrays and > dictionaries (called "objects" in JavaScript). Nested structures of > these two building blocks is a very potent combination. And Smalltalk > literal arrays only give us ONE of them. > >> May be you mean that you want to have the equivalent of { } but for >> dictionary, why not. > > Sigh. "Maybe"? Ok, things would be MUCH simpler if you actually read the > article you know. And no, not really, because {} is a *dynamic* array > with expressions in it and I am talking about (primarily) *literal* > dictionaries. > >> Having a syntax for a syntax is not really exciting. > > What? > >> Now I think that the key problem is dealing with reference between >> elements. for that STON can be better because why stopping at dictionary? >> But then the next question if we go down this >> road is why don't we add this syntax to smalltalk so that we can create >> literals objects like in Javascript. >> I mean without message send because this is exactly that no? >> What is the difference between >> Dictionary new add: #flop put: 33 ;yourself >> and >> {|% flop : 33 %|} >> >> or Person { >> name : 'stef' >> } > > The difference? Well, the first is an imperative Smalltalk program > (fully insecure of course since I presume you would parse and execute it > as full Smalltalk) and the second two are declarative literal syntaxes > that are safe to parse. > >> then this is not really Smalltalk anymore and we cannot say that we only >> have messages and the parser and â¦. >> have to be changedâ¦. This is why I asked what is the use case. > > Your reasoning is very... confusing. What do you mean "only have > messages" - we *already* have a whole bunch of literal syntax for > creating objects. What makes a Dictionary so special compared to Arrays? > > And "not really Smalltalk anymore"... ehm, I give up. > > Anyway, my article mainly says that Smalltalk literals go a long way BUT > without the support for Dictionaries they fall short of JSON, and that > is a bit of a shame I think. But still - the article was mainly food for > thought - I am not fighting a battle here, I am just exploring. > >> Finally and I still did not get a clear answer: why there is a need for >> dictionary syntax to store method meta data. > > Can you please stop referring to "method meta data" all the time? This > thread is about an article I wrote that you haven't read and it has > nothing to do with that use case. Ok? I agree but the discussion started out from the question how to do meta data exchange. Dale H. uses JSON for that at the moment. I do recommend to everybody to actually _read_ the article http://goran.krampe.se/2012/05/08/literal-arrays-vs-json-vs-ston-vs-tirade/. In the context of meta data exchange I agree with Stephane D. that literal arrays (something like s-expressions) can do the job; however the syntax is not well defined across dialects and as Dale points out with the nails and screws comparison it might not be all that user friendly. In terms of general data exchange I value this discussion of JSON, STON and Tirade. It is very useful for my work. So we actually have two use cases 1) exchange of meta data 2) exchange of general data with literal objects. This leads to the discussion: How are object literals done in Smalltalk? --Hannes > regards, GÃ¶ran > >

May 9, 2012

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

by H. Hirzel

On 5/8/12, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > StÃ©phane, > > On 08 May 2012, at 22:59, StÃ©phane Ducasse wrote: > >> Finally and I still did not get a clear answer: why there is a need for >> dictionary syntax to store method meta data. > > (I still think we are all discussing different things, and I do understand > your point, and I myself don't want to force STON on anybody). > > But a quick question then, since I know you also know Lisp. > > Do you then see array literal syntax as s-expressions ? Yes, I see them as such and for that I agree with Stephane D. that they may serve to store the meta data. But they are not all that readable and the semantics is not so easy to deduct. However that's a matter of taste. > So that dictionaries/maps are like Lisp plists ? Yes. And BTW, thank you all for this interesting discussion. We'll see where it leads to. It will help us all to get more insight into the matter of data exchange in a human readable and sustainable way. (i.e. parsers are available in various dialects and languages) --Hannes > Dictionary new > at: #x put: 1; > at: #y put; 2; > yourself. > > would then be encoded like > > #( x 1 y 2 ) > > ? > > Eventually doing a > > Dictionary newFromPairs:: #( x 1 y 2 ) > > ? > > It would certainly work, with the know limitation that one has to know or > understand the semantics upfront. > > Sven >

May 9, 2012

Re: [Pharo-project] Running in background with OSProcess

by David T. Lewis

On Tue, May 08, 2012 at 08:20:38AM -0700, Sean P. DeNigris wrote: > > Sean P. DeNigris wrote > > > > How do I circumvent all the processing and tell OSP what args to actually > > pass to the underlying system? > > > > I found a solution: > env := CommandShell new environment. > pwd := '/'. > args := Array > with: '-DJENKINS_HOME=/path with spaces/.jenkins' > with: '-jar' > with: '/path/with/another space/jenkins.war' > with: '--httpPort=####' > with: '--ajp13Port=####'. > desc := (Array with: nil with: nil with: nil). > p := PipeableOSProcess > new: '/usr/bin/java' > arguments: args > environment: env > descriptors: desc > workingDir: pwd > errorPipelineStream: nil. > > Since I'm not doing any redirecting, this works. If you have to redirect, it > looks like the best move would be to go through ProxyPipeline, like Dave > suggested, but define and plugin a custom ShellSyntax that does not do any > string processing... Sean, This is a good solution. It does exactly what you want, and the command parameters are clearly specified without relying on either /bin/sh or ShellSyntax to do the parsing. One last pointer: When Jenkins is done and your external process exits, it is good practice to close any open file descriptors (p closePipes). This will prevent file handle leaks if you run Jenkins on a regularly scheduled basis. Dave

May 9, 2012

Re: [Pharo-project] Improved version of StartupPreferences (+Windows)

by Ben Coman

Mariano Martinez Peck wrote: > On Tue, May 8, 2012 at 7:21 PM, Ben Coman <btc(a)openinworld.com> wrote: > > >> Mariano Martinez Peck wrote: >> >> >>> Hi guys. After playing a little bit with StartupPreferences, and >>> continuing >>> the effort of Ben (thanks Ben for yet another great tool), I generate a >>> improved (from my point of view) version of the tool. >>> >>> The main changes are: >>> >>> a) Previously the tool searched files 1) first in image directory, 2) then >>> in the preference folder and 3) finally in the general preference folder. >>> As soon as it found at least one file, I didn't continue with the rest of >>> the places. Now, it starts the other way around, from the most general to >>> the most spceific. Starts in 3), then 2) and finally 1) >>> >>> >> Moreover, it does >> >>> not stop when it finds files in any of them. So all are searched and >>> executed. It works or or less the same way as variables in UNIX with >>> .bashrc /etc/envirorment, etc... >>> >>> >>> >> Did it actually work like that? >> > > > yes > > > >> I thought it had worked for me processing more than one file from each >> preferences folders. >> > > > No. See the previous version: > > PreferenceHandler >> perform > > actions do: [:each | > > each value ifNotNil: [:res | ^ res ] > ]. > > ^#() > > > then the value was not nil (therefore, when there were found files), the > method just returned. > > > > >> It seemed only the image folder was restricted to a single specific file ' >> startup.st' I assume this was to avoid processing any other random .st >> files that might happen appear in the image folder. I had been considering >> a refactoring like your #lookInFolder, but was concerned about picking up >> random .st files in the image folder. >> >> >> > I copy paste here part of my future blog post (once this is integrated I > will publish it). This is how it works NOW in ORDER: > > > 1. The image folder: The startup only searches for a file called â > startup.stâ. So if you have such a file in the same directory where the > image is, then such script will be executed automatically. This type of > startup is usually used to do something that is application-specific or > something that only makes sense for the specific image you are using. > 2. Preference folder: This is a specific folder for a specific Pharo > version. This folder is in the $HOME (kind of) of the current OSâ user. > Therefore, this folder is shared for all the images you open. To know the > real value, print the result of âFileDirectory preferencesFolderâ. In my > case (in MaxOSX) and Pharo 2.0, it is â/Users/mariano/.config/pharo/2.0â². > In this place, StartupLoader will load ALL existing .st files. This type of > startup is useful when we have something to execute for all images of a > specific Pharo version. > 3. General preferences folder: this is similar to the previous one with > the difference that it is general for all Pharo versions. To know the > value, print âFileDirectory preferencesGeneralFolderâ, which in my case is > â/Users/mariano/.config/pharo/generalâ. This type of startup is useful when > we have something to execute for all images of any Pharo version. > > > > > >> I haven't gone through the your new methods in detail, but I've expanded >> your changes to the existing architecture to also resolve the issue with >> Windows. >> Basically I've thrown away what I was trying to do putting the configs >> into standard Microsoft locations. That was mainly to deal the location of >> config folders being hardcoded at two level down from root, which I have >> now removed this constraint. The config folder can now be located anywhere >> in the parent path from the image up to root. >> >> The key addition is #ascendingSearchForDirectory for which you can try >> these out... >> FileDirectory default ascendingSearchForDirectory: 'mariano' >> FileDirectory default ascendingSearchForDirectory: 'Users' >> FileDirectory default ascendingSearchForDirectory: 'Contents' "Valid >> for one-click image" >> FileDirectory default ascendingSearchForDirectory: FileDirectory >> configFolderLocalName FileDirectory preferencesGeneralFolder >> FileDirectory preferencesFolder >> >> >> > > Excellent. So it means that then it is working for Windows also? > > Yes. It works for Windows - now with the same (modified) logic as Unix. > >> b) I have created several class side methods (addAtStartup*) to create >> >>> given actions into the current directory. Previously, files were created >>> in >>> 2 folders at the same time and there were only the possibility to create >>> only in one place. Now you can add startup actions in any of the 3 places >>> mentioned in a) >>> >>> c) Added a whole protocol (remove* and clean*) to remove script files from >>> all folders of a) and also to clean the internal stored actions. >>> >>> d) Lots of internal refactors to reuse code and less hardcoding. >>> >>> Does someone want to take a look to the slice ? >>> Slice in inbox: http://code.google.com/p/**pharo/issues/detail?id=5835<http://code.google.com/p/pharo/issues/detail?id=5835> >>> >>> Cheers, >>> >>> >>> >>> >> >> > > >

May 8, 2012

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

by GÃ¶ran Krampe

Hi all! First - I am not fighting nor pushing in any direction. I just find the subject interesting. On 05/08/2012 10:59 PM, StÃ©phane Ducasse wrote: >>> :) there is no security problem just that gemstone does not have a parser. Because parsing cannot be a security hole >>> this is blind data interpretation that is a problem. This is why Github got problems and I imagine that the code was probably passed in JSON or similar format. >> >> Mmm, well, if you rely on full Compiler to parse literals, it is a security problem. But if you use the technique Igor showed to only parse array literals - then yes, that's safe, I agree. I forgot about his post. > > Parsing and compiling + execution are three different actions. > Parsing: stream -> tokens* but you know it. Of course. What I mean is that depending on how you "parse" a Smalltalk literal you may or may not be susceptible to a security hole. If you just blindly use the full Compiler to do the whole thing - then you have a hole. If you do not, then you don't. Igor showed a neat way to only use the literal array part of the parser - fine, no hole. But if you just use full Compiler - not fine. [SNIP] >> My point is that it would be nice if we actually had proper syntax for Associations (and or Dictionaries). > > OK I see. But what I want to say is that then this is not a literal array anymore. > Literal means that you only need a parser and no execution to get the information. Parse time. But Stephane... please *read* what I write in the article. Let me repeat: #-> is a message in Smalltalk, not a literal syntax. We all know that. BUT... there is nothing preventing us from adding support in the Smalltalk parser to handle this as a *literal* syntax that creates an Association. Tirade has support for it and a large part of the article talks about this, but I presume you have not read it. > Now I would like to know the use case for a dictionary syntax or association. There are TONS of use cases. The whole success behind JSON is IMHO based on the fact that it has explicit syntax for *both* arrays and dictionaries (called "objects" in JavaScript). Nested structures of these two building blocks is a very potent combination. And Smalltalk literal arrays only give us ONE of them. > May be you mean that you want to have the equivalent of { } but for dictionary, why not. Sigh. "Maybe"? Ok, things would be MUCH simpler if you actually read the article you know. And no, not really, because {} is a *dynamic* array with expressions in it and I am talking about (primarily) *literal* dictionaries. > Having a syntax for a syntax is not really exciting. What? > Now I think that the key problem is dealing with reference between > elements. for that STON can be better because why stopping at dictionary? But then the next question if we go down this > road is why don't we add this syntax to smalltalk so that we can create literals objects like in Javascript. > I mean without message send because this is exactly that no? > What is the difference between > Dictionary new add: #flop put: 33 ;yourself > and > {|% flop : 33 %|} > > or Person { > name : 'stef' > } The difference? Well, the first is an imperative Smalltalk program (fully insecure of course since I presume you would parse and execute it as full Smalltalk) and the second two are declarative literal syntaxes that are safe to parse. > then this is not really Smalltalk anymore and we cannot say that we only have messages and the parser and â¦. > have to be changedâ¦. This is why I asked what is the use case. Your reasoning is very... confusing. What do you mean "only have messages" - we *already* have a whole bunch of literal syntax for creating objects. What makes a Dictionary so special compared to Arrays? And "not really Smalltalk anymore"... ehm, I give up. Anyway, my article mainly says that Smalltalk literals go a long way BUT without the support for Dictionaries they fall short of JSON, and that is a bit of a shame I think. But still - the article was mainly food for thought - I am not fighting a battle here, I am just exploring. > Finally and I still did not get a clear answer: why there is a need for dictionary syntax to store method meta data. Can you please stop referring to "method meta data" all the time? This thread is about an article I wrote that you haven't read and it has nothing to do with that use case. Ok? regards, GÃ¶ran

May 8, 2012

[Pharo-project] Strangest object ever seen?

by Pavel Krivanek

Hi, If you take the latest Pharo 2.0 image from Jenkins (20059) and you execute the expression: (Metaclass allInstances select: [:c | c superclass = ProtoObject class]) inspect you will get an collection inspector where the first object is very strange one. It is very hard to get any useful information about the origin of this evil object. The only thing we know exactly is that it causes virtual machine segmentation faults while trying to export class ScrollBar via Fuel. Not only CogVM but even StackVM. Can you, please, try to help us to get as much information as possible about this object? I named it "dzindzik" :-) Cheers, -- Pavel

May 8, 2012