February 2010 - Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] Failing ECUntypedModelTest >> testNarrowWith

by Mariano Martinez Peck

On Mon, Feb 15, 2010 at 1:34 PM, Romain Robbes <romain.robbes(a)lu.unisi.ch>wrote: > yes, this test should either be deleted or rewritten. When I'm back > from holidays I'll look into it. > Ok. Don't worry. If your fix comes before I build next pharo dev, I integrate it, otherwise, I will remove it for a while and then if you do it we put it again. ok ? cheers mariano > Romain > > On Monday, February 15, 2010, Lukas Renggli <renggli(a)gmail.com> wrote: > > It is stupid to have tests that depend on what else is loaded in the > image. > > > > OB and RB (for some parts) use a fake image with fake classes and > > methods in which they run their test. > > > > Lukas > > > > 2010/2/14 Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> Hi Lukas/Romain. While building a PharoDev, I noticed that > >> ECUntypedModelTest >> testNarrowWith is failing. > >> > >> The problem is in: > >> > >> self assert: count > 100. > >> > >> as "count", which is equal to "model entries size", is 98. > >> > >> Of course, if I change it to > >> > >> self assert: count > 90. > >> > >> for example, it works prefect. > >> > >> I have no idea about this. What do you think ? > >> > >> Cheers > >> > >> Mariano > >> > >> _______________________________________________ > >> 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 > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > 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

[Pharo-project] FileSystem question

by stephane ducasse

|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

Feb. 15, 2010