- Pharo-dev - lists.pharo.org

Re: [Pharo-project] PhD and PostDoc topics with us at Lille :)

by StÃ©phane Ducasse

The deadline for a phd defense is 31 of december. What should be done is to give a date of the defense. Stef > Hi all > > INRIA is offering some PhD positions and we are looking for candidates (note that a commitee will decide not us). > Here are the topics for our team > > Reflection and Security in Dynamic Languages > http://www.inria.fr/travailler/mrted/en/doc/details.html?id=PNGFK026203F3VB… > > Software re-modularization > http://www.inria.fr/travailler/mrted/en/doc/details.html?id=PNGFK026203F3VB… > > Deadline for applying: Mai 4 > > > > for the postdoc you should have defended your PhD by end of October (I should check) > > Reflection and Scoping in Dynamic Languages > http://www.inria.fr/travailler/mrted/en/postdoc/details.html?id=PNGFK026203… > > > Designing a pure trait-based language > http://www.inria.fr/travailler/mrted/en/postdoc/details.html?id=PNGFK026203… > > Deadline for applying: Mars 14 > > please distribute :) > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 16, 2010

[Pharo-project] About new inspector

by StÃ©phane Ducasse

there is a really nice discussion on supporting (not having an inspector breaking) when browsing proxy. Can you have a look? http://code.google.com/p/pharo/issues/detail?id=1970 "What happens is the inspector asks for "self class allInstVarNames" and then tries to get each value with "self instVarNamed: aName". The problem is, self class allInstVarNames answers the instVars of the future class, but "self instVarNamed: aName" gets passed up to the MIMEDocument by #doesNotUnderstand: and the MIMEDocument throws an error because of course it doesn't have the correct instant vars. The old inspectors weren't as intrusive and worked, these new tools clearly still have some bugs. Since ProtoObject, the superclass for any such proxies doesn't do #instVarNamed:, such code in the inspector will blow up anytime one attempts to inspect any kind of proxy. I would report this as a bug to whoever is maintaining the new inspector tools." So the only way I know to produce the 'bug' is to load the SFuture class he describes in the blogpost I mention above then run the example I posted in step two. If this is the wrong place to report this then let me know and I'll keep looking for the correct place. Delete commentComment 4 by pdebruic, Today (14 hours ago) The default, I think. I haven't changed anything. SystemBrowser default Ctrl-p gives OBSystemBrowserAdaptor Delete commentComment 5 by marcus.denker, Today (11 hours ago) I think the problem is this: -> ProtoObject implements a *minimal* object. This way, Proxies or Futures can use #doesNotUnderstand to implement what they implement. That is, for the example of the Proxy, every message is forwarded to the remote object. -> Now we do not know what exactly you want to forward. Should an inspector inspect the local proxy? Ot the remote object? You decide. Your subclass of ProtoObject copies as many objects from Object as you want. (often all that are needed to inspect the *proxy* vs. the remote object). I think Ramon fine-tuned his implementation for the normal old inspector. Now when you use another one, it uses other methods in addition to the one implemented in the Future --> confusion. Chaos. Bug. But: We can not fix this. this is purely the responsibility of the implementor of the subclass of ProtoObject. So. next action: -> We fix (uhm, remove) the croquet Future code that is just plain confusing. -> We think hard if it's really a problem in the new inspector vs. a missing method on the Future. (and, yes, all this sucks anyway.... we are hard at work to make reflection better and solve all this in a *much* nicer way... but that's research...) Delete commentComment 6 by ramon.leon, Today (10 hours ago) It's not just the Future proxy that'll have problems, it's proxies in general. The way the current inspector is written won't work with any proxy I see in my image, SoapHref, SFuture, MAProxyObject, MADynamicObject, probably the Glorp record proxy, because it assume it can use #instVarNamed: on an instance using values from "anInstance class allInstVarNames" which in the case of *any* proxy won't work unless the proxy implements a version of #instVarNamed:. This is confusing because now the proxy is no longer behaving as a proxy, now reflectively it's answering values for itself rather than the instance being proxied. Another solution would be if the proxy overrode #class to return the class of the proxied instance, but I've always assumed all hell would break loose if you overrode #class, I didn't think it safe to do, and I've not seen any other proxy class do this. Regardless of the ultimate solution, the inspector shouldn't blow up, it should catch the exception and have some default rendering behavior for when it can't inspect an object for some reason. Do you not agree? Delete commentComment 7 by stephane.ducasse, Today (moments ago) Yes I agree. We should contact frederick. I think that the inspector should know that it is browsing a proxy and pay attention.

Feb. 16, 2010

Re: [Pharo-project] FileSystem question

by StÃ©phane Ducasse

Hi colin You confirmed what I like :) But my question was more about moving entry API to FSReference API. |working cache| working := FSDiskFilesystem current working. cache := working / 'package-cache'. cache entry cache entry creation. "--> 2010-02-14T10:34:31+00:00" cache entry modification. "--> 2010-02-14T10:34:31+00:00" cache entry size give me access to the file descriptor now I was wondering why we could not have the API of description at the level of FSreference to avoid that navigation code. cache creation. "--> 2010-02-14T10:34:31+00:00" cache modification. "--> 2010-02-14T10:34:31+00:00" cache size On Feb 16, 2010, at 8:23 AM, Colin Putney wrote: > stephane ducasse <stephane.ducasse(a)free.fr> wrote: > >> I like the way FSFilePluginPrims encapsulate the primitive calls. > > Lukas Renggli replied: > >> I think this is a separate object because some filesystems might not >> provide this information or might provide a different set of >> information. >> >> An external filesystem (FTP, HTTP) might not know the size, creation >> or modification timestamp. Zip archives might provide different >> information. I guess that's the reason why this is a separate object. > > Sort of. That's the rationale for handles. FSDiskHandle isolates the stream from the primitives, so it's possible to have the primitives in the handle and still have the stream work with different types of filesystems. I moved the primitives to a separate object for a several reasons: > > One was to make them private. The stream should not be able to call primitives directly, and putting them in a separate object that the stream doesn't have access to makes that clear. (It's not full capability security because the stream can violate encapsulation via #instVarAt: or other trickery, but the need to do that is a sign that you shouldn't). > > Second, the primitives provided by FilePlugin aren't ideal, and eventually I want to have some primitives designed specifically for Filesystem. It wouldn't be a drop-in replacement for FilePlugin, but if the FilePlugin primitives are all in one place, it should be fairly simple to port to another primitive object with a slightly different protocol. > > Finally, I like the way it looks: > > Primitives close: id > > is nicer than > > self primClose: id. > > at least to my eye. :-) > > Colin > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 16, 2010

Re: [Pharo-project] web services, pharo

by StÃ©phane Ducasse

cool :) On Feb 16, 2010, at 1:58 AM, Torsten Bergmann wrote: > Stefan wrote: >> What I would love to be able to do is to >> use the webcam of my machine to scan a book ISBN number >> and fetch all the data from a given provider. >> Does anybody have an idea how we could plug all that together. > > I remember Seabreaze for Seaside has a seaside barcode/webcam > reader component (using an online webservice to identify the item) > to do exactly that. > > I think it was in one of the videos at http://seabreeze.heeg.de/ > (one of the videos with Roland Wagner). Maybe you should try > the one-click image or ask on the seabreeze list. > > Bye > T. > -- > Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - > jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 16, 2010

Re: [Pharo-project] FileSystem question

by Colin Putney

stephane ducasse <stephane.ducasse(a)free.fr> wrote: > I like the way FSFilePluginPrims encapsulate the primitive calls. Lukas Renggli replied: > I think this is a separate object because some filesystems might not > provide this information or might provide a different set of > information. > > An external filesystem (FTP, HTTP) might not know the size, creation > or modification timestamp. Zip archives might provide different > information. I guess that's the reason why this is a separate object. Sort of. That's the rationale for handles. FSDiskHandle isolates the stream from the primitives, so it's possible to have the primitives in the handle and still have the stream work with different types of filesystems. I moved the primitives to a separate object for a several reasons: One was to make them private. The stream should not be able to call primitives directly, and putting them in a separate object that the stream doesn't have access to makes that clear. (It's not full capability security because the stream can violate encapsulation via #instVarAt: or other trickery, but the need to do that is a sign that you shouldn't). Second, the primitives provided by FilePlugin aren't ideal, and eventually I want to have some primitives designed specifically for Filesystem. It wouldn't be a drop-in replacement for FilePlugin, but if the FilePlugin primitives are all in one place, it should be fairly simple to port to another primitive object with a slightly different protocol. Finally, I like the way it looks: Primitives close: id is nicer than self primClose: id. at least to my eye. :-) Colin

Feb. 16, 2010

[Pharo-project] web services, pharo

by Torsten Bergmann

Stefan wrote: > What I would love to be able to do is to > use the webcam of my machine to scan a book ISBN number > and fetch all the data from a given provider. > Does anybody have an idea how we could plug all that together. I remember Seabreaze for Seaside has a seaside barcode/webcam reader component (using an online webservice to identify the item) to do exactly that. I think it was in one of the videos at http://seabreeze.heeg.de/ (one of the videos with Roland Wagner). Maybe you should try the one-click image or ask on the seabreeze list. Bye T. -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser

Feb. 16, 2010

Re: [Pharo-project] Making FFI non-intrusive (Was: Re: Pharo changing the game)

by Lukas Renggli

> Sorry, Lucas! Â This was because I started the closure work in a > Qwaq^H^H^H^HTeleplace image that lacked the pragma extensibility. Â So when > it came to port the Closure compiler to other dialects I a) didn't notice > the extensibility stuff and b) overwrite it. No problem, I thought that there was a particular reason that it got removed. > So what to do? Â Please point me to/email me a change set of the pragma > extensibility code and I will try to integrate it back into the closure > compiler as soon as time allows. These are the methods #primitive: and #primitive:module: that carry the <primitive> pragma to tell the compiler that these pragmas have to be considered during compilation: Parser>>primitive: anIntegerOrString "Create indexed primitive." <primitive> ^ anIntegerOrString isInteger ifTrue: [ anIntegerOrString ] ifFalse: [ anIntegerOrString isString ifTrue: [ self primitive: anIntegerOrString module: nil ] ifFalse: [ self expected: 'Indexed primitive' ] ] Parser>>primitive: aNameString module: aModuleStringOrNil "Create named primitive." <primitive> (aNameString isString and: [ aModuleStringOrNil isNil or: [ aModuleStringOrNil isString ] ]) ifFalse: [ ^ self expected: 'Named primitive' ]. self allocateLiteral: (Array with: (aModuleStringOrNil isNil ifFalse: [ aModuleStringOrNil asSymbol ]) with: aNameString asSymbol with: 0 with: 0). ^ 117 Then the primitive are setup from ... Parser>>pragmaPrimitives | pragmas primitives | self properties pragmas isEmpty ifTrue: [ ^ 0 ]. pragmas := Pragma allNamed: #primitive from: self class to: Parser. primitives := self properties pragmas select: [ :prim | pragmas anySatisfy: [ :prag | prag selector = prim keyword ] ]. primitives isEmpty ifTrue: [ ^ 0 ]. primitives size = 1 ifFalse: [ ^ self notify: 'Ambigous primitives' ]. ^ primitives first message sendTo: self .. which in turn is called from Parser>>method: doit context: ctxt encoder: encoderToUse to calculate the primitive number. Maybe this wasn't the smartest idea after all? I made this so that FFI (and other libraries) could easily extend the range of possible primitive types, but since it was never used it is probably sort of pointless? Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 15, 2010

Re: [Pharo-project] Making FFI non-intrusive (Was: Re: Pharo changing the game)

by Eliot Miranda

On Sat, Feb 13, 2010 at 11:29 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > >>> It is interesting to note that of course, after this was added to 3.9, > there was > >>> someone *very hard* arguing that adding Pragmas was a very dumb idea... > >>> > >>> Who that person was is left as an exercise to the reader of course ;-) > >> > >> Hint: FFI has its own proprietary hardcoded pragma format. It > >> unnecessary complicates the compiler even when not loaded. Not to > >> mention that it breaks all tools that have their own parser, such as > >> RB for example. > >> > > > > I'd like to discuss, what changes to compiler we may introduce to allow > FFI > > to handle pragmas in non-intrusive manner. > > I suppose something, like registration mechanism for compiler, where > > any external package can > > register and provide own handler(s) for pragmas. > > Then, of course, an Encoder should have a public API, which would > > allow such handlers to add/change literals > > and method header. > > > > We already having at least another use of pragmas - preferences. It's > > also could use same mechanism which can > > be used to notify a preferences system about appearance of new or > > removal existing preferences as a result of method compilation. > > In fact we had that in Squeak 3.9 and early Pharo versions. I even > wrote code that adapted this mechanism for FFI, but the FFI maintainer > insisted on sticking with his compiler hacks. > > The idea was that you could add methods with a specific pragma to one > of the compiler classes (I don't remember which one). There was also > one such method for each of the Smalltalk primitives currently > supported (#primitive:, 3primitive:module:, ...). When encountering a > pragma in the source code the compiler would check if this was a > compiler-pragma with the same name defined and perform that method. In > the case of the primitive the compiler would change the compile method > to use the configured primitive. A very strait forward use of pragmas. > > However the functionality that made compiler pragmas and primitives > extensible is gone today even in Pharo. For reasons unknown to me > Eliot removed all the code when he added the closure support. Back to > hacking and patching the compiler. > Sorry, Lucas! This was because I started the closure work in a Qwaq^H^H^H^HTeleplace image that lacked the pragma extensibility. So when it came to port the Closure compiler to other dialects I a) didn't notice the extensibility stuff and b) overwrite it. I am *very much* in favour of pragma extensibility. Look at what we did in VisualWorks (of which you're probably aware), where the pragmas that are compilable in a class are defined by pragma methods on the class side. We use pragma methods to introduce pragmas so that pragmas added in different packages don't collide in a single class-side pragma method. So what to do? Please point me to/email me a change set of the pragma extensibility code and I will try to integrate it back into the closure compiler as soon as time allows. Apologies. Eliot > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 15, 2010

Re: [Pharo-project] HelpSystem implementation

by Danny Chan

Am Sonntag, 14. Februar 2010 21:19:57 schrieb Torsten Bergmann: > Hi Danny, > > > - What is the reason to have HelpBuilder and to create a hierarchy of > > HelpTopic instances mirroring the layout of the actual content classes? > > Why > > not use the class objects directly? > > HelpBuilder builds the topics/books from code. I just wanted to decouple > the storage mechanism (here ST source code). Topics/books could also > be stored in an external database/files or even created on the fly from > dynamic information. > I've thought a bit about this. I see two problems with this. Let's say I want to create a book with high level documentation about a package. But one chapter should be the complete API documentation. The easiest way would be if he could write documentation in the current way and for the sub books return in addition one object that generates the needed nodes automatically. It seems to me that it would be easier if the content node knows how to retrieve its data. Secondly, let's say I want to browse the whole API of the system. Because building the nodes is a separate step and the HelpTopic/HelpBook instances do not know how to do this, I would need to create the whole help content before browsing, and this takes quite some time I guess. I would prefer to have a simple protocol to query a node for its contents and its sub books. Then specific subclasses could implement the required fetching behaviour. I will try to find some time to write actual code to show what I mean. Danny

Feb. 15, 2010

Re: [Pharo-project] FileSystem question

by Lukas Renggli

I think this is a separate object because some filesystems might not provide this information or might provide a different set of information. An external filesystem (FTP, HTTP) might not know the size, creation or modification timestamp. Zip archives might provide different information. I guess that's the reason why this is a separate object. Lukas On 15 February 2010 18:36, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > |working cache| > working := FSDiskFilesystem current working. > cache := working / 'package-cache'. > cache entry > Â Â Â Â cache entry creation. Â Â "--> 2010-02-14T10:34:31+00:00" > Â Â Â Â cache entry modification. "--> 2010-02-14T10:34:31+00:00" > Â Â Â Â cache entry size > > give me access to the file descriptor now I was wondering why we could not have > the API of description at the level of FSreference to avoid that navigation code. > > Â cache creation. Â Â "--> 2010-02-14T10:34:31+00:00" > Â cache modification. "--> 2010-02-14T10:34:31+00:00" > Â cache size > > > I like the way FSFilePluginPrims encapsulate the primitive calls. > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 15, 2010