March 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] pharoconf | mooseday | 2013 - 2nd call for participation

by Tudor Girba

Just a reminder: if you plan to attend PharoConf and/or MooseDay, please register as soon as possible. Cheers, Doru Begin forwarded message: > From: Tudor Girba <tudor(a)tudorgirba.com> > Subject: [Esug-list] pharoconf | mooseday | 2013 - call for participation > Date: March 17, 2013 8:56:41 PM GMT+01:00 > To: Moose-dev Moose Dev <moose-dev(a)iam.unibe.ch>, "Pharo-project(a)lists.gforge.inria.fr Development" <pharo-project(a)lists.gforge.inria.fr>, A friendly place where any question about pharo is welcome <pharo-users(a)lists.gforge.inria.fr>, ESUG Mailing list <esug-list(a)lists.esug.org>, Seaside - general discussion <seaside(a)lists.squeakfoundation.org>, vwnc nc <vwnc(a)cs.uiuc.edu> > > (please distribute) > > We are happy to invite you to the PharoConf | MooseDay | 2013: > http://scg.unibe.ch/wiki/events/pharoconf-mooseday-2013 > > The conference will take place at the University of Bern during April 2-4: > - PharoConf (April 2,3) > - MooseDay (April 4) > > The conference will be free and will even include a free lunch. Yes, free lunch. No trick. > We only kindly ask you to register online for each event as soon as possible. > > STUDENT SPONSORSHIPS: > > ESUG will sponsor the travel of up to 10 students with 150 EUR / person. > Please apply for sponsorship by mail at esug-info(a)esug.org. First-come, first-served. > > The conference sponsors will sponsor the travel of up to 10 students with up to 200 CHF / person. > Please apply for sponsorship before the conference by mail at tudor(a)tudorgirba.com. First-come, first-served. > > IMPORTANT > If you are a student, please bring your student cards with you to help us limit the lunch costs. > > Cheers, > The organizers > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org -- www.tudorgirba.com "Next time you see your life passing by, say 'hi' and get to know her."

March 26, 2013

Re: [Pharo-project] Some issues with UDP sockets in Pharo 1.4/Pharo 2.0

by Sven Van Caekenberghe

Hi Holger, On 26 Mar 2013, at 12:12, Holger Hans Peter Freyther <holger(a)freyther.de> wrote: > Hi, > > I am porting a tooling class that I wrote on GST for my SIP and MGCP code > to Pharo. This class will create a socket and then fork a RX and TX process. > I have some issues with 'stopping' the socket. I have created an example > that shows the issue in Pharo 2.0 and Pharo 1.4 with the pharovm (and to > have more debug output with a re-compiled one). > > > | s rx | > s := Socket newUDP. > rx := [ > [s waitForData. s halt] > on: ConnectionClosed do: [ s halt] > ] fork. > "Wait for the process to hit the readSemaphore" > (Delay forSeconds: 3) wait. > s close. > > > My expectation is that I will get the ConnectionClosed signal or at least > that >>#waitForData will return once the socket is closed. This is based > on reading the comment of >>#waitForData. > > > The Socket>>#waitForData documentation reads like this: > "Wait for data to arrive. This method will block until > data is available or the socket is closed. If the socket is closed > a ConnectionClosed exception will be signaled." > > > I had a look at the socket plugin and the following is happening. First > aio is disabled, the state set to ThisEndClosed, then ::close is called > and in the above case the result is '0' and the following code will be > executed: > > else if (0 == result) > { > /* close completed synchronously */ > SOCKETSTATE(s)= Unconnected; > FPRINTF((stderr, "closeConnection: disconnected\n")); > SOCKET(s)= -1; > } > > > this means that my 'rx' process will happily wait on the readSemaphore > of the Socket and will never be woken up. > > > My question are probably: > > 1.) Is this the intended behavior for Socket>>#close and Socket>>#waitForData? > 2.) How should I terminate my RX process? > > kind regards > holger > > PS: The issue is probably socket specific and not related to UDP. Maybe I am telling you things you already know, but TCP and UDP are fundamentally different. UDP is really one-shot, try-and-hope, completely asynchronous. In networking you generally only get a ConnectionClosed when you actually read or write (and even then ;-). The Socket API has many strange methods, most of which you should not touch. You should use SocketStream. Looking in the VM code is also misleading because the 3 platforms (Mac, Win, *nix) are different. In Socket[Stream] there is lots of historic baggage. I would suggest you look at Smalltalk code that actually works (for TCP, Zinc Client and Server code would do, for UDP, ZTimestampSNTPClient for example). For your concrete question (2): just start a reading process, wrap it in a handler and clean up. For UDP this will never happen: you will keep on reading nothing. For TCP reading will eventually fail if the other end disappears. HTH, Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

March 26, 2013

Re: [Pharo-project] GSoC idea: Spec over Aida component model

by Benjamin

Thanks for the explanation :) My question was more Can I be a student for project Foo and a mentor for project Bar ? :) Ben On Mar 26, 2013, at 8:41 PM, Janko MivÅ¡ek <janko.mivsek(a)eranova.si> wrote: > Hi Benjamin > > Dne 26. 03. 2013 16:04, piÅ¡e Benjamin: >> Of course I could be a mentor :) >> >> But my question is can I be a mentor and a student ? > > Unfortunatelly not :( > >> And this proposal go in the direction I want Spec to follow: >> platform/framework independency :) >> I know that Nico would love to have Spec running in Amber ^^ > > So you'd like to run as a student for the Spec Independency project, > which is also your proposal, so this is actually a Student proposal, > right? :) > > In any case your project can be a good one in parallel to Spec over Aida > one. And another over Amber? That way we can evolve Spec while testing > it in many frameworks at once. But it seems that we all need to adjust a > terminology a bit, HTML5 terms are a bit different, those ins W3C Web > Components spec different again, etc. Then event architecture could be > different that one in web browser's DOM tree. Then MVC, dependency > mechanism, how ideas from JavaScript MVC frameworks like Ember.js, > Angular.js etc, can be covered with Spec. In any case, pretty amusing > projects indeed :) > > Best regards > Janko > >> >> Ben >> >> On Mar 26, 2013, at 3:49 PM, Janko MivÅ¡ek <janko.mivsek(a)eranova.si >> <mailto:janko.mivsek@eranova.si>> wrote: >> >>> Guys, would be this an interesting project to advance Smalltalk UI more >>> toward bleeding edge again, after 30 years, when we were there already >>> with MVC based GUI? Spec project have a potential here and Spec over web >>> frameworks to build fully desktop-capable web apps seems to be >>> achievable. Spec over Amber (who will propose that?), Spec over Aida, >>> Spec over Seaside? Benjamin, would you be a co-mentor of that project? >>> >>> Title: Spec over Aida for desktop-capable Web Apps >>> >>> Level: advanced >>> >>> Possible mentor: Janko MivÅ¡ek >>> >>> Possible second mentor: Benjamin? >>> >>> Description >>> >>> Spec as a means to describe and generate GUI has a potential to help >>> building web applications as well. And because one of Spec goals is to >>> become a platform/framework independent, this project has a goal to >>> extend Aida component model for building Single Page web apps to become >>> Spec-aware >>> >>> >>> Technical Details >>> >>> Aida has a component model for building so called Single Page web UIs, >>> capable of composing a hierarchy of so called web widgets, which are >>> standalone reusable components, together with hierarchical web form >>> support. Spec as descriptor and generator of UI is therefore a natural >>> extension of Aida component model. When a HTML5 Web Components standard >>> will be ready, Aida component model can be easily extended to support >>> that standard as well, together with Spec (and maybe UIBuilder too?). >>> >>> Benefits to the Student >>> >>> Student will acquire the knowledge and experience of building >>> desktop-capable UIs on the web using HTML5 approach. >>> >>> Benefits to the Community >>> >>> Spec has a potential to become a de-facto standard way of describing >>> User Interfaces for Smalltalk projects from desktop to web and mobile, >>> on a dialect and web framework neutral way. This project can contribute >>> a piece toward that goal. >>> >>> >>> Best regards >>> Janko >>> >>> >>> -- >>> Janko MivÅ¡ek >>> Aida/Web >>> Smalltalk Web Application Server >>> http://www.aidaweb.si >>> >> > > -- > Janko MivÅ¡ek > Aida/Web > Smalltalk Web Application Server > http://www.aidaweb.si >

March 26, 2013

Re: [Pharo-project] GSoC idea: Spec over Aida component model

by Janko MivÅ¡ek

Hi Benjamin Dne 26. 03. 2013 16:04, piÅ¡e Benjamin: > Of course I could be a mentor :) > > But my question is can I be a mentor and a student ? Unfortunatelly not :( > And this proposal go in the direction I want Spec to follow: > platform/framework independency :) > I know that Nico would love to have Spec running in Amber ^^ So you'd like to run as a student for the Spec Independency project, which is also your proposal, so this is actually a Student proposal, right? :) In any case your project can be a good one in parallel to Spec over Aida one. And another over Amber? That way we can evolve Spec while testing it in many frameworks at once. But it seems that we all need to adjust a terminology a bit, HTML5 terms are a bit different, those ins W3C Web Components spec different again, etc. Then event architecture could be different that one in web browser's DOM tree. Then MVC, dependency mechanism, how ideas from JavaScript MVC frameworks like Ember.js, Angular.js etc, can be covered with Spec. In any case, pretty amusing projects indeed :) Best regards Janko > > Ben > > On Mar 26, 2013, at 3:49 PM, Janko MivÅ¡ek <janko.mivsek(a)eranova.si > <mailto:janko.mivsek@eranova.si>> wrote: > >> Guys, would be this an interesting project to advance Smalltalk UI more >> toward bleeding edge again, after 30 years, when we were there already >> with MVC based GUI? Spec project have a potential here and Spec over web >> frameworks to build fully desktop-capable web apps seems to be >> achievable. Spec over Amber (who will propose that?), Spec over Aida, >> Spec over Seaside? Benjamin, would you be a co-mentor of that project? >> >> Title: Spec over Aida for desktop-capable Web Apps >> >> Level: advanced >> >> Possible mentor: Janko MivÅ¡ek >> >> Possible second mentor: Benjamin? >> >> Description >> >> Spec as a means to describe and generate GUI has a potential to help >> building web applications as well. And because one of Spec goals is to >> become a platform/framework independent, this project has a goal to >> extend Aida component model for building Single Page web apps to become >> Spec-aware >> >> >> Technical Details >> >> Aida has a component model for building so called Single Page web UIs, >> capable of composing a hierarchy of so called web widgets, which are >> standalone reusable components, together with hierarchical web form >> support. Spec as descriptor and generator of UI is therefore a natural >> extension of Aida component model. When a HTML5 Web Components standard >> will be ready, Aida component model can be easily extended to support >> that standard as well, together with Spec (and maybe UIBuilder too?). >> >> Benefits to the Student >> >> Student will acquire the knowledge and experience of building >> desktop-capable UIs on the web using HTML5 approach. >> >> Benefits to the Community >> >> Spec has a potential to become a de-facto standard way of describing >> User Interfaces for Smalltalk projects from desktop to web and mobile, >> on a dialect and web framework neutral way. This project can contribute >> a piece toward that goal. >> >> >> Best regards >> Janko >> >> >> -- >> Janko MivÅ¡ek >> Aida/Web >> Smalltalk Web Application Server >> http://www.aidaweb.si >> > -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

March 26, 2013

Re: [Pharo-project] More GSoC ideas wanted, 3 days left ....

by Yuriy Tymchuk

Hi Janko, To be honest, you are touching Java only by parsing it's code. Yes, it's shifted towards Java because there is a lot of Java code that is ready to be analyzed, but all work is done in Smalltalk. Moreover you have to keep model generic, and this means that you have to work also with a Smalltalk model and probably tweak it. This is a great opportunity for student to compare languages and indeed see how much simpler Smalltalk is. That's how I see it. Regards Yuriy On 26 Ð±ÐµÑ. 2013, at 19:56, Janko MivÅ¡ek <janko.mivsek(a)eranova.si> wrote: > Privet Yuriy, > > Idea included, just that I'm wondering a bit if this one is a bit too > Java and not much Smalltalk specific. Would you explain a bit more? > Also, what others think? > > Best regards > Janko > > > Dne 26. 03. 2013 15:56, piÅ¡e Yuriy Tymchuk: >> Title: FAST Java Model >> >> Level: intermediate >> >> Possible mentor: Nikolas Anquetil >> >> Possible second mentor: Yuriy Tymchuk >> >> Description: For in depth source code analysis a support of abstract >> syntax trees is required. FAST is an abstract syntax tree extension for >> FAMIX meta-model that is used by Moose technology. The goal of this >> project is to create a Java version of FAST. >> >> Technical Details: As programming languages are different, their AST >> representations are different too. FAST model aims for creation of as >> generic as possible core that can be extended for different languages. >> Also the structure of a model allows creation of generic algorithms like >> symbol resolution, metrics calculation and rule checking that will work >> for any language. A prototype of FAST for Smalltalk is already >> implemented by Yuriy Tymchuk as well as couple of nodes for Java. During >> the project a student will implement the rest of the Java model, and >> improve some parts of PetitJava parser that is used by FAST. >> >> Benefits to the Student: The student will gain a deep understanding of >> a Java syntax and abstract syntax tree model. He will also learn about >> PetitParser framework, and gain knowledge about software modeling and >> analysis. >> >> Benefits to the Community: Community will get a FAST model for Java >> that can be used for software assessment with Moose. Also this model can >> be used later in PhD projects such as automation of source code >> translation form C++ to Java. >> >> On 26 Ð±ÐµÑ. 2013, at 12:36, Janko MivÅ¡ek <janko.mivsek(a)eranova.si >> <mailto:janko.mivsek@eranova.si>> wrote: >> >>> Dear Pharoers, >>> >>> Ideas are slowly coming, 14 so far, but this is way below the 30+ in >>> previous years. So, stretch your brain, come with some more ideas, which >>> will be interesting for potential students and of course useful for our >>> community. Students you are again welcome to propose such idea by your >>> own. One student idea for now! >>> >>> Ideas so far: http://gsoc2013.esug.org/ideas >>> >>> To propose an idea just respond to this post by fulfilling this idea >>> template: >>> >>> Title: >>> >>> Level: (beginner, intermediate, advanced) >>> >>> Possible mentor: (if already known) >>> >>> Possible second mentor: (if already known) >>> >>> Description >>> >>> Technical Details >>> >>> Benefits to the Student >>> >>> Benefits to the Community >>> >>> Best regards >>> Serge and Janko, >>> your this year GSoC admins >>> >>> >>> -- >>> Janko MivÅ¡ek >>> Aida/Web >>> Smalltalk Web Application Server >>> http://www.aidaweb.si >>> >> > > -- > Janko MivÅ¡ek > Aida/Web > Smalltalk Web Application Server > http://www.aidaweb.si >

March 26, 2013

Re: [Pharo-project] More GSoC ideas wanted, 3 days left ....

by Janko MivÅ¡ek

Privet Yuriy, Idea included, just that I'm wondering a bit if this one is a bit too Java and not much Smalltalk specific. Would you explain a bit more? Also, what others think? Best regards Janko Dne 26. 03. 2013 15:56, piÅ¡e Yuriy Tymchuk: > Title: FAST Java Model > > Level: intermediate > > Possible mentor: Nikolas Anquetil > > Possible second mentor: Yuriy Tymchuk > > Description: For in depth source code analysis a support of abstract > syntax trees is required. FAST is an abstract syntax tree extension for > FAMIX meta-model that is used by Moose technology. The goal of this > project is to create a Java version of FAST. > > Technical Details: As programming languages are different, their AST > representations are different too. FAST model aims for creation of as > generic as possible core that can be extended for different languages. > Also the structure of a model allows creation of generic algorithms like > symbol resolution, metrics calculation and rule checking that will work > for any language. A prototype of FAST for Smalltalk is already > implemented by Yuriy Tymchuk as well as couple of nodes for Java. During > the project a student will implement the rest of the Java model, and > improve some parts of PetitJava parser that is used by FAST. > > Benefits to the Student: The student will gain a deep understanding of > a Java syntax and abstract syntax tree model. He will also learn about > PetitParser framework, and gain knowledge about software modeling and > analysis. > > Benefits to the Community: Community will get a FAST model for Java > that can be used for software assessment with Moose. Also this model can > be used later in PhD projects such as automation of source code > translation form C++ to Java. > > On 26 Ð±ÐµÑ. 2013, at 12:36, Janko MivÅ¡ek <janko.mivsek(a)eranova.si > <mailto:janko.mivsek@eranova.si>> wrote: > >> Dear Pharoers, >> >> Ideas are slowly coming, 14 so far, but this is way below the 30+ in >> previous years. So, stretch your brain, come with some more ideas, which >> will be interesting for potential students and of course useful for our >> community. Students you are again welcome to propose such idea by your >> own. One student idea for now! >> >> Ideas so far: http://gsoc2013.esug.org/ideas >> >> To propose an idea just respond to this post by fulfilling this idea >> template: >> >> Title: >> >> Level: (beginner, intermediate, advanced) >> >> Possible mentor: (if already known) >> >> Possible second mentor: (if already known) >> >> Description >> >> Technical Details >> >> Benefits to the Student >> >> Benefits to the Community >> >> Best regards >> Serge and Janko, >> your this year GSoC admins >> >> >> -- >> Janko MivÅ¡ek >> Aida/Web >> Smalltalk Web Application Server >> http://www.aidaweb.si >> > -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

March 26, 2013

Re: [Pharo-project] Suggestion about Phexample and StateSpecs(Mocketry) integration

by Denis Kudriashov

2013/3/26 Yuriy Tymchuk <yuriy.tymchuk(a)me.com> > Ok, and what if we will change behavior a bit so if no definitions were > found it will send the incoming message to enclosed object? This way it > will work like phexample but will also allow to define some fancy DSL. > We can copy all phexample syntax methods into single class inside StateSpecs package but replace implementation with pragmas approach. So anybody can browse implementors like usual and it will not required any special cases. How I can influence your interest, guys? I can provide cleaning, comments, improvements to StateSpecs. I opened for your requirements. Phexample become quite popular and can be part of Pharo sometimes. Mocketry/StateSpecs used by people too. It would be bad if this packages can't be used together. > > On 26 Ð±ÐµÑ. 2013, at 07:46, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hello > 2013/3/26 Camillo Bruni <camillobruni(a)gmail.com> > >> Definitely StateSpec looks more mature and can be used in a more flexible >> way. >> But I am not a big fan of the pragma magic. Why? >> It breaks all tools for me :/. If I see a message send I want to be able >> to: >> - browse it, so I can see who implements it? >> - debug it directly to get to the real method. >> >> SateSpec does indeed help writing readable code by allowing almost >> grammatically >> correct sentences. However I don't think this is the way to program. I am >> a big >> fan of stupid english: >> >> `foo should isKindOf: Bar` vs. `foo should be an instance of: Bar` >> >> If I want to figure out how the first one works, I can simply browse the >> implementors of #should and/or #isKindOf: where is the StateSpec version >> I am >> lost. I have to rely on "contains string literal" to get the sources, for >> me >> that is very strange. >> > > I think main thing you want is easilly explore all available should > syntax. And StateSpecs can be easilly adopted for such task. We can just > move all methods with syntax pragmas to single class. So you can open this > class and see what available. > > To get implementors of some "should expression" you should use senders > search of syntax words instead of implementors. Syntax words in StateSpecs > is just method literals ( <syntax: #(be an instance of:)>, #() is just > array of symbols). > > Interesting that StateSpecs has more explicit syntax system. How you can > explore in Phexample expression: > > object should be true > ? > > You have separate PheMatcher>>be and PheMatcher>>true methods and there is > no places in code where you can see that this messages can and should be > used together. > But with StateSpecs you should put pragma with explicit expression like: > > Equal>>true: anObject > <syntax: #(be true)> > ^self return: (IdentitySpec pattern: true) > > So with StateSpecs you have full syntax expression at one place which can > be easy explored. > And for example to support Phexample mesage #beTrue you should just add > another pragma: > > Equal>>true: anObject > <syntax: #(be true)> > <syntax: #(beTrue)> > ^self return: (IdentitySpec pattern: true) > > So with Phexample you can browse implementors of "single word should > expressions". But with Phexample if you browse implementors of #be like > messages you have no idea how it can be used. > In StateSpecs you should use senders. And with StateSpecs if you browse > "any syntax word implementors" by senders seach you will see all possible > usage cases. And if I move all methods with syntax pragmas to single class > you can easilly see all possible expressions in one place. > > `foo should isKindOf: Bar` vs. `foo should be an instance of: Bar` >> > > With StateSpecs it should be > > foo should be a kind of: Bar > > And as I said before It is simple task to support all Phexample > expressions by StateSpecs pragmas > > Best regards, > Denis > > >

March 26, 2013

Re: [Pharo-project] GSoC13: Google Summer of Code started, your ideas please!

by Francisco Garau

Yeah, I wish I could push that a bit further... I've recently found a similar type of work for Python. Google for "Starkiller, Salib", if you are interested. - Francisco On 26 Mar 2013, at 11:17, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > > On Mar 26, 2013, at 12:05 PM, Frank Shearar <frank.shearar(a)gmail.com> wrote: > >> That includes both Francisco Garau's and Santiago Bragagnolo's work on >> Concrete Type Inference, > > yes we should build on top of them. > I wish francisco would like to continue pushing his master with us but he is busy with banks :) > >> Roel Wuyt's RoelTyper and my own tiny >> inference engine in SqueakCheck >> (http://www.squeaksource.com/SqueakCheck/ and its ConfigurationOf >> might well need fixing for Pharo). >> >> frank >

March 26, 2013

[Pharo-project] [Help to review/test] Crash when downloading FFI

by Guillermo Polito

Hi! I've given a shot trying to get a fix for this case. Thanks to Eliot, I think I reached a solution, but since I had some random results at first, I'd like if someone else can take 5 minutes and validate. https://pharo.fogbugz.com/f/cases/10134/SpecialObjectsArray-should-not-chan… To test, the following snippet does not have to crash: Gofer it smalltalkhubUser: 'DBXTalk' project: 'DBXTalkDriver'; configurationOf: 'OpenDBXDriver'; loadStable. Thanks very much! Guille

March 26, 2013

Re: [Pharo-project] [Vm-dev] Re: Reproducible VM crash when loading FFI

by Guillermo Polito

I removed the extra message send (just in case to get this version) | newSpecialObjectsArray oldSpecialObjectsArray | newSpecialObjectsArray := self newSpecialObjectsArray. oldSpecialObjectsArray := self specialObjectsArray. self vm voidCogVMState. oldSpecialObjectsArray becomeForward: newSpecialObjectsArray Which so far works fine :D !! I'll publish a slice for people to test. Thank you very much for the help!! On Tue, Mar 26, 2013 at 5:52 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > Hi Guille, > > On Tue, Mar 26, 2013 at 9:33 AM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> >> Ok, as a summary. I've tried >> >> 1) not recreating the compact classes array without voiding vm caches: >> works ok. >> >> 2) making another compact classes array, voiding the vm caches >> (primitive 214): random crashes :/. Sometimes it works, some times it does >> not... >> I've tried, just for the record, to void the cache before, after and >> (before and after) the become forward of the special objects array: >> > > You need to void the cache *after* creating the new array and *immediately > before* installing it. Voiding the cache before creating it gives the VM > too much time to run and recache. So try > > d) > | newSpecialObjectsArray | > newSpecialObjectsArray := self newSpecialObjectsArray. > self vm voidCogVMState. > self specialObjectsArray becomeForward: newSpecialObjectsArray > > a) >> | newSpecialObjectsArray | >> self vm voidCogVMState. >> newSpecialObjectsArray := self newSpecialObjectsArray. >> self specialObjectsArray becomeForward: newSpecialObjectsArray. >> >> b) >> | newSpecialObjectsArray | >> newSpecialObjectsArray := self newSpecialObjectsArray. >> self specialObjectsArray becomeForward: newSpecialObjectsArray. >> self vm voidCogVMState. >> >> c) >> | newSpecialObjectsArray | >> self vm voidCogVMState. >> newSpecialObjectsArray := self newSpecialObjectsArray. >> self specialObjectsArray becomeForward: newSpecialObjectsArray. >> self vm voidCogVMState. >> >> All with different results when executing several times... :/ >> >> voidCogVMState is the following in Pharo: >> >> VirtualMachine class>>voidCogVMState >> "Void any internal caches the VM maintains other than the method lookup >> caches. >> These comprise >> - the stack zone, where method activations are stored, and >> - the machine code zone, where the machine code form of CompiledMethods >> is held." >> <primitive: 214> >> ^self primitiveFailed >> >> The comment says it does not clean method lookup caches... >> > > Right, and that's fine. We're only wanting to discard cached machine code > etc. > >> >> any ideas? >> > > As explained, try d). > > >> Guille >> >> On Tue, Mar 26, 2013 at 11:48 AM, Guillermo Polito < >> guillermopolito(a)gmail.com> wrote: >> >>> Ok, first I'm sorry for the evil upload. That was the first at hand >>> :$. I'll get a more trustful way to do it the next one... >>> Second, thanks for taking the time to look at it :). >>> >>> Now, I've some questions: >>> >>> - this "bug" is particular to Cog, isn't it? I mean, only related to >>> inlining with JIT, so a Stack vm does not play with these rules, right? >>> - Why is voiding the cache hackish? I mean, replacing the special >>> objects array is a very low level operation, and a very special one which >>> is not commonly performed. Voiding the cache looks like normal to me in >>> such a case... >>> >>> Tx! >>> Guille >>> >>> On Mon, Mar 25, 2013 at 11:56 PM, Eliot Miranda <eliot.miranda(a)gmail.com >>> > wrote: >>> >>>> >>>> >>>> >>>> On Mon, Mar 25, 2013 at 3:22 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: >>>> >>>>> >>>>> Thanks for the findings! >>>>> >>>> >>>> you're welcome :) >>>> >>>> >>>>> >>>>> I opened an issue http://bugs.pharo.org/issues/id/10134 with the >>>>> contents >>>>> of your solution. >>>>> >>>>> I think for completeness we should implement both solution, and of >>>>> course >>>>> use the one that does not #becomeForward: in the standard case. >>>>> >>>> >>>> To be clear, becomeForward: is the correct way to install the >>>> specialObjectsArray. The issue is what entries in the specialObjectsArray >>>> need to remain constant. The Character table, the compactClassesArray, all >>>> the classes and a few other entries (semaphores, etc) must remain the same. >>>> This could do with better documenting of the method :-/ >>>> >>>> >>>> >>>>> >>>>> On 2013-03-25, at 19:52, Eliot Miranda <eliot.miranda(a)gmail.com> >>>>> wrote: >>>>> > Hi Guille, >>>>> > >>>>> > thanks for this. The problem is that Pharo's >>>>> > recreateSpecialObjectsArray uses newCompactClassesArray to recreate >>>>> the >>>>> > compact classes array and on Cog that is not supported. Cog caches >>>>> the >>>>> > compactClassesArray (specialObjectsArray at: 29) in every jitted >>>>> method >>>>> > prolog to reduce the time taken to derive the receiver's class in >>>>> message >>>>> > lookup. The Pharo 2.0 code for recreating the specialObjectsArray >>>>> can >>>>> > therefore create a dangling pointer where the only reference to the >>>>> old >>>>> > compactClassesArray is in machine code, and the machine code GC >>>>> doesn't >>>>> > cope with there being roots in machine code. Note that Cog also >>>>> caches the >>>>> > characterTable and class SmallInteger in machine code. >>>>> > >>>>> > There are two solutions to this. >>>>> > One would be to reuse the compactClassesArray (my recommendation). >>>>> So that >>>>> > recreateSpecialObjectsArray looks like >>>>> > >>>>> > ... >>>>> > "An array of the 255 Characters in ascii order. >>>>> > Cog inlines table into machine code at: prim so do not regenerate >>>>> it." >>>>> > newArray at: 25 put: Character characterTable. >>>>> > ... >>>>> > "A 32-element array with up to 32 classes that have compact >>>>> instances. >>>>> > Cog inlines table into machine code class lookup so do not >>>>> regenerate it." >>>>> > newArray at: 29 put: self compactClassesArray. >>>>> > ... >>>>> > >>>>> > where compactClassesArray, like Character characterTable, answers the >>>>> > existing object. >>>>> > >>>>> > The second solution (rather hackish) is to void all machine code on >>>>> > installing the new specialObjectsArray. e.g. >>>>> > recreateSpecialObjectsArray >>>>> > "Smalltalk recreateSpecialObjectsArray" >>>>> > "To external package developers: >>>>> > **** DO NOT OVERRIDE THIS METHOD. ***** >>>>> > If you are writing a plugin and need additional special object(s) >>>>> for your >>>>> > own use, >>>>> > use addGCRoot() function and use own, separate special objects >>>>> registry " >>>>> > "The Special Objects Array is an array of objects used by the Squeak >>>>> > virtual machine. >>>>> > Its contents are critical and accesses to it by the VM are >>>>> unchecked, so >>>>> > don't even >>>>> > think of playing here unless you know what you are doing." >>>>> > "Replace the interpreter's reference in one atomic operation. >>>>> > Void machine code to avoid crashing Cog." >>>>> > | newSpecialObjectsArray | >>>>> > newSpecialObjectsArray := self newSpecialObjectsArray. >>>>> > self specialObjectsArray becomeForward: newSpecialObjectsArray. >>>>> > Smalltalk vm voidCogVMState >>>>> > >>>>> > >>>>> > this is my fault for not ensuring recreateSpecialObjectsArray was >>>>> properly >>>>> > commented. I had commented the inlining of Character table, but not >>>>> the >>>>> > inlining of the CompactClasses array. Apologies. >>>>> > >>>>> > HTH, >>>>> > Eliot >>>>> > >>>>> > On Sat, Mar 23, 2013 at 10:19 AM, Guillermo Polito < >>>>> > guillermopolito(a)gmail.com> wrote: >>>>> > >>>>> >> Hi! >>>>> >> >>>>> >> In my quest to crash the vm, i've found an ugly common case :(. >>>>> >> I am trying to port the opendbx driver to 2.0, but I'm getting vm >>>>> crashes >>>>> >> when my configuration loads FFI :(. I updated my configuration to >>>>> load >>>>> >> version 1.7 of FFI (which I assume is the latest). >>>>> >> >>>>> >> I tried to do it in Pharo 2.0 with latest pharovm, and with eliot's >>>>> Cog >>>>> >> 2701 from his website, failing in both cases. >>>>> >> The snippet of code that gets a sistematic crash is: >>>>> >> >>>>> >> Gofer it >>>>> >> smalltalkhubUser: 'DBXTalk' project: 'DBXTalkDriver'; >>>>> >> package: 'ConfigurationOfOpenDBXDriver'; >>>>> >> load. >>>>> >> ((Smalltalk at: #ConfigurationOfOpenDBXDriver) project >>>>> version:#stable) >>>>> >> load >>>>> >> >>>>> >> >>>>> >> This snippet crashes always with a segmentation fault (at least the >>>>> >> fifteen times i tried :), with several different output in the >>>>> console... >>>>> >> >>>>> >> Surprisingly, if I load FFI alone and not from the OpenDBXDriver >>>>> >> configuration, it loads well... :/ >>>>> >> >>>>> >> So I'm deferring the OpenDBX port a bit longer :( >>>>> >> >>>>> >> Thanks! >>>>> >> Guille >>>>> >> >>>>> > >>>>> > >>>>> > >>>>> > -- >>>>> > best, >>>>> > Eliot >>>>> >>>>> >>>> >>>> >>>> -- >>>> best, >>>> Eliot >>>> >>>> >>> >> >> > > > -- > best, > Eliot > >

March 26, 2013