February 2011 - Pharo-users

Re: [Pharo-users] [Pharo-project] [ANN] JNIPort 2.0 for VisualWorks, Pharo and Squeak

by Tudor Girba

Sounds great! What are the impediments of getting it to work with Cog on Pharo? Cheers, Doru On 5 Feb 2011, at 16:14, Joachim Geidel wrote: > JNIPort 2.0 for VisualWorks, Pharo and Squeak is now available! > > JNIPort is a Smalltalk library which allows Java code to be invoked from > Smalltalk. It acts as a bridge between the world of Smalltalk objects and a > Java Virtual Machine (JVM) where Java code is executing. For more > information see > > http://jniport.wikispaces.com > > JNIPort 2.0 for VisualWorks can be loaded from the Cincom Public Store > Repository and from the JNIPort wiki at > > http://jniport.wikispaces.com/Downloads > > JNIPort 2.0 for Pharo and Squeak is available from SqueakSource at > > http://www.squeaksource.com/JNIPort.html > > and from the JNIPort wiki. > > The changes from JNIPort 1.9 are: > > - JNIPort can now be used in Pharo and Squeak. > > - Packages have been renamed such that the can be shared between Store > and Monticello. > > - Platform specific code has been moved to separate packages to make the > core packages portable between VisualWorks, Pharo, and Squeak. > > - The much-critized _null postfix used for selectors of wrapper methods > which don't have arguments is gone. > > - A few bugs have been fixed. > > Installation instructions for VisualWorks are on the JNIPort wiki, > instructions for Pharo and Squeak are on the wiki of the JNIPort project > page of SqueakSource. I strongly encourage you to read the instructions > before installing and using JNIPort. > > JNIPort 2.0 has been tested with: > > - VisualWorks from 7.5 to 7.8 (trent dec10.3) on Mac OS X 10.6.6 and > Windows XP SP 3 > > - VisualWorks from 7.7 to 7.8 (trent dec10.3) on Ubuntu 10.04 (64bit) > with both the 32-bit and the 64-bit VisualWorks VMs > > - Squeak 4.2 on Mac OS X 10.6.6 and Windows XP SP 3 > > - Pharo 1.1.1 and 1.2 on Mac OS X 10.6.6 and Windows XP SP 3 > > Known issues: > > - In Pharo 1.1.1, you may encounter an error when JNIPort tries to register > a new Java object in an internal weak dictionary. This is a bug in Pharo's > implementation of this collection class. I can't do anything about it. If > you can't live with it, please upgrade to Pharo 1.2. > > - JNIPort for Pharo and Squeak currently cannot be used with the Cog VM. > > - Callbacks from foreign operating system threads cannot be used in Pharo > and Squeak. The Alien foreign function interface does not yet support > this feature. When you run the unit tests, three tests will fail because > of this restriction. These failures are expected and do not indicate bugs. > > Best regards, > Joachim Geidel -- www.tudorgirba.com "Don't give to get. Just give."

Feb. 5, 2011

[ANN] JNIPort 2.0 for VisualWorks, Pharo and Squeak

by Joachim Geidel

JNIPort 2.0 for VisualWorks, Pharo and Squeak is now available! JNIPort is a Smalltalk library which allows Java code to be invoked from Smalltalk. It acts as a bridge between the world of Smalltalk objects and a Java Virtual Machine (JVM) where Java code is executing. For more information see http://jniport.wikispaces.com JNIPort 2.0 for VisualWorks can be loaded from the Cincom Public Store Repository and from the JNIPort wiki at http://jniport.wikispaces.com/Downloads JNIPort 2.0 for Pharo and Squeak is available from SqueakSource at http://www.squeaksource.com/JNIPort.html and from the JNIPort wiki. The changes from JNIPort 1.9 are: - JNIPort can now be used in Pharo and Squeak. - Packages have been renamed such that the can be shared between Store and Monticello. - Platform specific code has been moved to separate packages to make the core packages portable between VisualWorks, Pharo, and Squeak. - The much-critized _null postfix used for selectors of wrapper methods which don't have arguments is gone. - A few bugs have been fixed. Installation instructions for VisualWorks are on the JNIPort wiki, instructions for Pharo and Squeak are on the wiki of the JNIPort project page of SqueakSource. I strongly encourage you to read the instructions before installing and using JNIPort. JNIPort 2.0 has been tested with: - VisualWorks from 7.5 to 7.8 (trent dec10.3) on Mac OS X 10.6.6 and Windows XP SP 3 - VisualWorks from 7.7 to 7.8 (trent dec10.3) on Ubuntu 10.04 (64bit) with both the 32-bit and the 64-bit VisualWorks VMs - Squeak 4.2 on Mac OS X 10.6.6 and Windows XP SP 3 - Pharo 1.1.1 and 1.2 on Mac OS X 10.6.6 and Windows XP SP 3 Known issues: - In Pharo 1.1.1, you may encounter an error when JNIPort tries to register a new Java object in an internal weak dictionary. This is a bug in Pharo's implementation of this collection class. I can't do anything about it. If you can't live with it, please upgrade to Pharo 1.2. - JNIPort for Pharo and Squeak currently cannot be used with the Cog VM. - Callbacks from foreign operating system threads cannot be used in Pharo and Squeak. The Alien foreign function interface does not yet support this feature. When you run the unit tests, three tests will fail because of this restriction. These failures are expected and do not indicate bugs. Best regards, Joachim Geidel

Feb. 5, 2011

Pharocasts: StringCalculator Kata

by laurent laffont

This is the first Kata proposed by the 12meses12katas<http://www.12meses12katas.com/> (12 months 12 katas) initiative. You will learn: Test-Driven Development, the Pharo way. Recorded and edited by Rafael Luque <http://vimeo.com/user1627267> (big thank you!). Here: http://www.pharocasts.com/2011/02/stringcalculator-kata.html Laurent Laffont - @lolgzs <http://twitter.com/#!/lolgzs> Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/

Feb. 5, 2011

Re: [Pharo-users] TFFiler: creates file containers to store external files in Monticello

by StÃ©phane Ducasse

> Stef, > > After re-reading, I'm not sure I addressed your question. no problem! this is already a nice way to package package resources. > > My plan is to include file container classes along with the rest of > the classes in my projects when I check them in to Monticello. That > way the version of the external files and the compatible version of > the source code is kept together. > > Of course, the file container content is opaque to Monticello and > nothing like a diff tool would be useful in perusing versions of the > external files unless it understood how to decode and uncompress the > file container's contents. > > TF > > On Fri, Feb 4, 2011 at 11:51 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >>> >>> (I was actually glad to see FileSystem delayed, as I made heavy use of >>> FileDirectory in TFFiler.) >> >> :) >> But if you look at the existing code in pharo you can faint :) >> >>> >>> Best regards, >>> TF >>> >>> >>> >>> >>> >>> >>> On Fri, Feb 4, 2011 at 11:12 AM, StÃ©phane Ducasse >>> <stephane.ducasse(a)inria.fr> wrote: >>>> Argh I want that! >>>> Now tony tell us what is the principle. >>>> I was thinking to add a git entry to a squeaksource but how do you manage them? >>>> Stef >>>> >>>>> >>>>> I've published a tool I'm using called TFFiler. >>>>> >>>>> My problem was that I had a number of external files that were >>>>> required for my Seaside web application. These were CSS, Javascript, >>>>> and image files that had to be placed in a specific directory tree >>>>> structure. When I moved my web app to another system, I always had to >>>>> remember to reconstruct the external directory tree. Over time, the >>>>> directory tree got larger and more complex. >>>>> >>>>> For deployment, I wanted the files to be served by Apache and not the >>>>> Seaside ExternalFileLibrary. (ExternalFileLibrary was the most >>>>> convenient approach during development.) This meant the directory tree >>>>> should be moved to a location other than the Pharo Resources >>>>> directory, which was the most convenient location during development. >>>>> >>>>> The current version of Monticello does not provide a way to save >>>>> external files with a project. TFFiler addresses this shortcoming. Now >>>>> when I load my project from Monticello the necessary external files >>>>> are deployed automatically. >>>>> >>>>> Maybe someone else will find this useful as well. >>>>> >>>>> http://www.tonyfleig.com/smallthoughts/blog/tffiler >>>>> http://www.squeaksource.com/TFFiler >>>>> >>>>> Regards, >>>>> TF >>>>> >>>> >>>> >>>> >>> >> >> >> >

Feb. 4, 2011

Re: [Pharo-users] TFFiler: creates file containers to store external files in Monticello

by Tony Fleig

Stef, After re-reading, I'm not sure I addressed your question. My plan is to include file container classes along with the rest of the classes in my projects when I check them in to Monticello. That way the version of the external files and the compatible version of the source code is kept together. Of course, the file container content is opaque to Monticello and nothing like a diff tool would be useful in perusing versions of the external files unless it understood how to decode and uncompress the file container's contents. TF On Fri, Feb 4, 2011 at 11:51 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >> (I was actually glad to see FileSystem delayed, as I made heavy use of >> FileDirectory in TFFiler.) > > :) > But if you look at the existing code in pharo you can faint :) > >> >> Best regards, >> TF >> >> >> >> >> >> >> On Fri, Feb 4, 2011 at 11:12 AM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> Argh I want that! >>> Now tony tell us what is the principle. >>> I was thinking to add a git entry to a squeaksource but how do you manage them? >>> Stef >>> >>>> >>>> I've published a tool I'm using called TFFiler. >>>> >>>> My problem was that I had a number of external files that were >>>> required for my Seaside web application. These were CSS, Javascript, >>>> and image files that had to be placed in a specific directory tree >>>> structure. When I moved my web app to another system, I always had to >>>> remember to reconstruct the external directory tree. Over time, the >>>> directory tree got larger and more complex. >>>> >>>> For deployment, I wanted the files to be served by Apache and not the >>>> Seaside ExternalFileLibrary. (ExternalFileLibrary was the most >>>> convenient approach during development.) This meant the directory tree >>>> should be moved to a location other than the Pharo Resources >>>> directory, which was the most convenient location during development. >>>> >>>> The current version of Monticello does not provide a way to save >>>> external files with a project. TFFiler addresses this shortcoming. Now >>>> when I load my project from Monticello the necessary external files >>>> are deployed automatically. >>>> >>>> Maybe someone else will find this useful as well. >>>> >>>> http://www.tonyfleig.com/smallthoughts/blog/tffiler >>>> http://www.squeaksource.com/TFFiler >>>> >>>> Regards, >>>> TF >>>> >>> >>> >>> >> > > >

Feb. 4, 2011

Re: [Pharo-users] TFFiler: creates file containers to store external files in Monticello

by StÃ©phane Ducasse

> > (I was actually glad to see FileSystem delayed, as I made heavy use of > FileDirectory in TFFiler.) :) But if you look at the existing code in pharo you can faint :) > > Best regards, > TF > > > > > > > On Fri, Feb 4, 2011 at 11:12 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> Argh I want that! >> Now tony tell us what is the principle. >> I was thinking to add a git entry to a squeaksource but how do you manage them? >> Stef >> >>> >>> I've published a tool I'm using called TFFiler. >>> >>> My problem was that I had a number of external files that were >>> required for my Seaside web application. These were CSS, Javascript, >>> and image files that had to be placed in a specific directory tree >>> structure. When I moved my web app to another system, I always had to >>> remember to reconstruct the external directory tree. Over time, the >>> directory tree got larger and more complex. >>> >>> For deployment, I wanted the files to be served by Apache and not the >>> Seaside ExternalFileLibrary. (ExternalFileLibrary was the most >>> convenient approach during development.) This meant the directory tree >>> should be moved to a location other than the Pharo Resources >>> directory, which was the most convenient location during development. >>> >>> The current version of Monticello does not provide a way to save >>> external files with a project. TFFiler addresses this shortcoming. Now >>> when I load my project from Monticello the necessary external files >>> are deployed automatically. >>> >>> Maybe someone else will find this useful as well. >>> >>> http://www.tonyfleig.com/smallthoughts/blog/tffiler >>> http://www.squeaksource.com/TFFiler >>> >>> Regards, >>> TF >>> >> >> >> >

Feb. 4, 2011

Re: [Pharo-users] TFFiler: creates file containers to store external files in Monticello

by Tony Fleig

Hi Stef, It is quite simple really. (It had to be for me to figure it out.) First a class of the specified name is constructed. Then the files are read in, compressed with gzip and encoded into base-64 strings. Then a class method is created for each file that answers that string. The class method is named with a base-36 encoding of the file path in order to ensure a valid method name. A dictionary of the base36-encoded method names keyed by the file path is created and that is serialized with ReferenceStream, compressed, and base-64-encoded as well. A class method called #fileList is created that reverses the process to re-create the original dictionary. To restore a file, it is looked up in the fileList dictionary by its path and then the corresponding method is invoked to obtain the encoded content. The content is then decoded, uncompressed, and written to the file path. There are a number of class methods copied from TFFiler into the file container class that is created for such things as adding, removing, replacing, displaying, and listing the file container's contents as well as redirecting the file restoring to alternate destination. The created file container class contains a class comment that lists the contents of the file container. It is updated as necessary when files are added or removed. (I was actually glad to see FileSystem delayed, as I made heavy use of FileDirectory in TFFiler.) Best regards, TF On Fri, Feb 4, 2011 at 11:12 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Argh I want that! > Now tony tell us what is the principle. > I was thinking to add a git entry to a squeaksource but how do you manage them? > Stef > >> >> I've published a tool I'm using called TFFiler. >> >> My problem was that I had a number of external files that were >> required for my Seaside web application. These were CSS, Javascript, >> and image files that had to be placed in a specific directory tree >> structure. When I moved my web app to another system, I always had to >> remember to reconstruct the external directory tree. Over time, the >> directory tree got larger and more complex. >> >> For deployment, I wanted the files to be served by Apache and not the >> Seaside ExternalFileLibrary. (ExternalFileLibrary was the most >> convenient approach during development.) This meant the directory tree >> should be moved to a location other than the Pharo Resources >> directory, which was the most convenient location during development. >> >> The current version of Monticello does not provide a way to save >> external files with a project. TFFiler addresses this shortcoming. Now >> when I load my project from Monticello the necessary external files >> are deployed automatically. >> >> Maybe someone else will find this useful as well. >> >> http://www.tonyfleig.com/smallthoughts/blog/tffiler >> http://www.squeaksource.com/TFFiler >> >> Regards, >> TF >> > > >

Feb. 4, 2011

Re: [Pharo-users] TFFiler: creates file containers to store external files in Monticello

by StÃ©phane Ducasse

Argh I want that! Now tony tell us what is the principle. I was thinking to add a git entry to a squeaksource but how do you manage them? Stef > > I've published a tool I'm using called TFFiler. > > My problem was that I had a number of external files that were > required for my Seaside web application. These were CSS, Javascript, > and image files that had to be placed in a specific directory tree > structure. When I moved my web app to another system, I always had to > remember to reconstruct the external directory tree. Over time, the > directory tree got larger and more complex. > > For deployment, I wanted the files to be served by Apache and not the > Seaside ExternalFileLibrary. (ExternalFileLibrary was the most > convenient approach during development.) This meant the directory tree > should be moved to a location other than the Pharo Resources > directory, which was the most convenient location during development. > > The current version of Monticello does not provide a way to save > external files with a project. TFFiler addresses this shortcoming. Now > when I load my project from Monticello the necessary external files > are deployed automatically. > > Maybe someone else will find this useful as well. > > http://www.tonyfleig.com/smallthoughts/blog/tffiler > http://www.squeaksource.com/TFFiler > > Regards, > TF >

Feb. 4, 2011

Re: [Pharo-users] [Seaside] TFFiler: creates file containers to store external files in Monticello

by Sven Van Caekenberghe

Great idea Tony, this is indeed quite useful. Thanks (again) for sharing this and for doing all the documentation work! Sven On 04 Feb 2011, at 19:17, Tony Fleig wrote: > I've published a tool I'm using called TFFiler. > > My problem was that I had a number of external files that were > required for my Seaside web application. These were CSS, Javascript, > and image files that had to be placed in a specific directory tree > structure. When I moved my web app to another system, I always had to > remember to reconstruct the external directory tree. Over time, the > directory tree got larger and more complex. > > For deployment, I wanted the files to be served by Apache and not the > Seaside ExternalFileLibrary. (ExternalFileLibrary was the most > convenient approach during development.) This meant the directory tree > should be moved to a location other than the Pharo Resources > directory, which was the most convenient location during development. > > The current version of Monticello does not provide a way to save > external files with a project. TFFiler addresses this shortcoming. Now > when I load my project from Monticello the necessary external files > are deployed automatically. > > Maybe someone else will find this useful as well. > > http://www.tonyfleig.com/smallthoughts/blog/tffiler > http://www.squeaksource.com/TFFiler > > Regards, > TF > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Feb. 4, 2011

TFFiler: creates file containers to store external files in Monticello

by Tony Fleig

I've published a tool I'm using called TFFiler. My problem was that I had a number of external files that were required for my Seaside web application. These were CSS, Javascript, and image files that had to be placed in a specific directory tree structure. When I moved my web app to another system, I always had to remember to reconstruct the external directory tree. Over time, the directory tree got larger and more complex. For deployment, I wanted the files to be served by Apache and not the Seaside ExternalFileLibrary. (ExternalFileLibrary was the most convenient approach during development.) This meant the directory tree should be moved to a location other than the Pharo Resources directory, which was the most convenient location during development. The current version of Monticello does not provide a way to save external files with a project. TFFiler addresses this shortcoming. Now when I load my project from Monticello the necessary external files are deployed automatically. Maybe someone else will find this useful as well. http://www.tonyfleig.com/smallthoughts/blog/tffiler http://www.squeaksource.com/TFFiler Regards, TF

Feb. 4, 2011