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

Re: [Pharo-project] Fwd: Amber git repo moved to the amber organisation

by Manfred KrÃ¶hnert

Hello Phil, On Mon, Mar 4, 2013 at 7:59 AM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > Now, the getting started links look like gone or not working nicely on > github's Wiki > I updated some incorrect links. Feel free to mention any other nonworking links you find. > It is hard to find http://amber-lang.net/documentation.html#Tutorials > from there. > I added a link to the Wiki page. Thanks for the hints. Best, Manfred

March 5, 2013

[Pharo-project] new Cog VMs available

by Eliot Miranda

at http://www.mirandabanda.org/files/Cog/VM/VM.r2697/ CogVM binaries as per VMMaker.oscog-eem.270/r2697 Fix the become issue where methods that are identical are failing the code test because their penultimate literals are different objects. Add a flag "cmUsesPenultimateLit" to jitted methods, stealing bits from stackCheckOffset (which was way larger than needed). Shrink stackCheckOffset to 12 bits (still an order of magnitude larger than needed) and add an error check on assigning it. Also add a check for max method size (2^16-1 bytes) and refuse to jit a method that generates too much code. When comparing code, use the cmUsesPenultimateLit flag to decide if comparison includes penultimate lit or not. This is mildly insane, but the VM really doesn't know about the penultimate literal and it shouldn't depend on knowing it can be ignored. Note that the CoInterpreter knows about the last literal; it uses this in supersends. With this hack, Pharo's condenseSources works. Fix bug in primitiveClone/cloneContext: that causes the copy to be a word short. Use isPointerNonInt: and isContextNonInt: in a few places. Implement unknownBytecode. Send unknownBytecode to the activeContext on unknown bytecode if the selector is in the specialObjectsArray. Fix page size bug in platforms/Cross/vm/sqHeapMap.c. -- best, Eliot

March 5, 2013

[Pharo-project] osprocess in pharo 2.0

by Tudor Girba

Hi, For some reason I thought that OSProcess was integrated in Pharo 2.0, but it appears that it is not in the image. Did I understand the issue incorrectly, or was the class renamed to something else? If it is not in the image, was it already ported to SmalltalkHub? (I could not find it) I am asking because I would like to know if we should continue to load OSProcess explicitly with Moose. Cheers, Doru -- www.tudorgirba.com "Not knowing how to do something is not an argument for how it cannot be done."

March 5, 2013

Re: [Pharo-project] [update 2.0] #20578

by Esteban Lorenzano

the dependence was introduced because it is needed to inform the system about certain system changes (concretely, method moved and method repackaged). of course, we can refactor it (in 3.0) On Mar 5, 2013, at 8:18 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Mar 5, 2013, at 9:53 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > >> Hi, >> >> the problem is that you have added the new dependency on RPackage to >> the Kernel, namely to >> ClassDescription>>addAndClassifySelector:withMethod:inProtocol:notifying:. > > I think that RPackage should be in the core and we should remove categories. > > And UsersManager should not be in the image. > >> >> I solved it with a next little hack in the loading script but we >> should rethink the role in RPackage in the kernel. And I think we >> should make our beta policy stricter to avoid serious changes like >> this and UsersManager integration in the beta stage. >> >> Cheers, >> -- Pavel >> >> On Sat, Mar 2, 2013 at 11:26 AM, Pavel Krivanek >> <pavel.krivanek(a)gmail.com> wrote: >>> This update broke some Pharo Kernel jobs. I will look at it later. >>> >>> -- Pavel >>> >>> On Fri, Mar 1, 2013 at 3:16 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>> 20578 >>>> ----- >>>> >>>> Issue 7617: make NBExternalEnumeration a subclass of SharedPool again >>>> https://code.google.com/p/pharo/issues/detail?id=7617 >>>> >>>> Issue 7605: moving a method into an extension does not notify the monticello package >>>> https://code.google.com/p/pharo/issues/detail?id=7605 >>>> >>>> Issue 7590: Kill MC History Data (>8MB of the image...) >>>> https://code.google.com/p/pharo/issues/detail?id=7590 >>>> >>>> Issue 7553: tons [delaySemaphore wait] process alive in image >>>> https://code.google.com/p/pharo/issues/detail?id=7553 >>>> (this one for check if it is fixed) >>>> >>>> Diff information: >>>> http://ss3.gemstone.com/ss/Pharo20/NativeBoost-Core-EstebanLorenzano.116.di… >>>> http://ss3.gemstone.com/ss/Pharo20/Kernel-EstebanLorenzano.1324.diff >>>> >>>> >> > >

March 5, 2013

Re: [Pharo-project] DBXTalk and Pharo 2.0

by Guillermo Polito

On Tue, Mar 5, 2013 at 8:22 PM, stephane ducasse <stephane.ducasse(a)free.fr>wrote: > > On Mar 5, 2013, at 12:52 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > > > Guillermo wrote: > >> The last time I tried to load DBXTalk in 2.0 the image hang up when > loading > >> FFI :(. So probably we should think on switching to NB FFI, but it will > >> take some time... > > > > Mhhh ... when I load ConfigurationOfFFI configuration browser > > and then manually load "FFI-Tests-tbn.6" from > > http://source.squeakfoundation.org/FFI all tests are green on Windows. > > > > And yes - migrating to NB makes sense! > > > >> BTW, since Igor has worked on the bundling of native libraries, we can > >> probably do that with the dbxtalk native libs also :) > > > > OK - looks like the infrastructure is ready. What is required to do that? > > Will you send the libraries to Igor and he just bundles them? > > That would be cool and save many people a lot of time. > > But accessing sql libs is not core so I would like to avoid to have a vm > with all the > librairies people used. You do not ***Imagine*** the amount of energy and > time > igor spent on making cairo backend be working on the three platforms. > Actually for dbxtalk, I normally end up compiling all the 1.4.6 libs by myself and distribute them since there is no official binaries for that... :/ > > >> All dbxtalk should be working in 1.4 so far. I also try to update it > with > >> the contributions of people but sometimes my hands are full :). > > > > thanks for that. It is a very important project and I would like to > > see it easily installable and working in Pharo 2.0 too. > > > > Sven wrote: > >> I use it in 2.0 to access Postgresql databases using Glorp + the native > (socket based) PostgresV2 driver. > >> This works fine. > > > > So we should put the config into the working configs for 2.0? > > > > Thx > > T. > > > > >

March 5, 2013

Re: [Pharo-project] Is this possible with XMLWriter?

by stephane ducasse

mariano I migrated Pastell which is a library to manipulate XML to PharoExtras. Have a look Stef On Mar 5, 2013, at 3:27 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Thank you all guys. Indeed, it was quite possible to manually build the DOM. > I was confused because the package was called "XMLParser". I could see the nodes and all the DOM but I didn't expected these classes would understand "writing behavior" like #named: , #add: etc... but yes, they do understand so you can manually build the DOM and when you are done you can just get the resulting string. > > Best, > > On Thu, Feb 28, 2013 at 12:50 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > Please use the version that is now published in PharoExtras. > If you add tests please commit them :) > > > On Feb 27, 2013, at 6:55 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > >> Hi guys. I am using XMLWriter from http://www.squeaksource.com/XMLWriter to write a specific XML that a protocol expects. >> What I need is to build the XML file from parent to children and dynamically. For example, I want to be able to define a tag, but then, later on, add more tags to a parent element. >> I found this impossible to do with the current XMLWriter. Here, messages like #tag:with: , #with: do not help. >> I know I will need to build everything in memory and send a "write contents" at the end to get the final XML string... >> >> For example, say I wanna build this XML: >> >> <root> >> <parent1> >> <child1>grrr<child1> >> <child2>grrr<child2> >> </parent1> >> <parent2> >> <child3>buhhh<child3> >> </parent2> >> </root> >> >> i would like an API like this: >> >> | xmlWriter | >> xmlWriter := XMLWriter new. >> xmlWriter tag: 'root'. >> (xmlWriter named: 'root') tag: 'parent1'. >> (xmlWriter named: 'parent1') tag: 'child' with: 'grrr'. >> (xmlWriter named: 'root') tag: 'parent2'. >> .... >> xmlWriter write contents. >> >> >> Or even if I don't have #named: but I can store them in instVars it would be fine: >> >> | xmlWriter rootTag parent1Tag | >> xmlWriter := XMLWriter new. >> rootTag xmlWriter tag: 'root'. >> parent1Tag rootTag tag: 'parent1'. >> parent1Tag tag: 'child' with: 'grrr'. >> rootTag tag: 'parent2' >> xmlWriter write contents. >> >> >> Any ideas how to do this? >> >> Thanks, >> >> -- >> Mariano >> http://marianopeck.wordpress.com > > > > > -- > Mariano > http://marianopeck.wordpress.com

March 5, 2013

Re: [Pharo-project] DBXTalk and Pharo 2.0

by stephane ducasse

On Mar 5, 2013, at 12:52 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Guillermo wrote: >> The last time I tried to load DBXTalk in 2.0 the image hang up when loading >> FFI :(. So probably we should think on switching to NB FFI, but it will >> take some time... > > Mhhh ... when I load ConfigurationOfFFI configuration browser > and then manually load "FFI-Tests-tbn.6" from > http://source.squeakfoundation.org/FFI all tests are green on Windows. > > And yes - migrating to NB makes sense! > >> BTW, since Igor has worked on the bundling of native libraries, we can >> probably do that with the dbxtalk native libs also :) > > OK - looks like the infrastructure is ready. What is required to do that? > Will you send the libraries to Igor and he just bundles them? > That would be cool and save many people a lot of time. But accessing sql libs is not core so I would like to avoid to have a vm with all the librairies people used. You do not ***Imagine*** the amount of energy and time igor spent on making cairo backend be working on the three platforms. >> All dbxtalk should be working in 1.4 so far. I also try to update it with >> the contributions of people but sometimes my hands are full :). > > thanks for that. It is a very important project and I would like to > see it easily installable and working in Pharo 2.0 too. > > Sven wrote: >> I use it in 2.0 to access Postgresql databases using Glorp + the native (socket based) PostgresV2 driver. >> This works fine. > > So we should put the config into the working configs for 2.0? > > Thx > T. >

March 5, 2013

Re: [Pharo-project] [update 2.0] #20578

by StÃ©phane Ducasse

On Mar 5, 2013, at 9:53 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > the problem is that you have added the new dependency on RPackage to > the Kernel, namely to > ClassDescription>>addAndClassifySelector:withMethod:inProtocol:notifying:. I think that RPackage should be in the core and we should remove categories. And UsersManager should not be in the image. > > I solved it with a next little hack in the loading script but we > should rethink the role in RPackage in the kernel. And I think we > should make our beta policy stricter to avoid serious changes like > this and UsersManager integration in the beta stage. > > Cheers, > -- Pavel > > On Sat, Mar 2, 2013 at 11:26 AM, Pavel Krivanek > <pavel.krivanek(a)gmail.com> wrote: >> This update broke some Pharo Kernel jobs. I will look at it later. >> >> -- Pavel >> >> On Fri, Mar 1, 2013 at 3:16 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> 20578 >>> ----- >>> >>> Issue 7617: make NBExternalEnumeration a subclass of SharedPool again >>> https://code.google.com/p/pharo/issues/detail?id=7617 >>> >>> Issue 7605: moving a method into an extension does not notify the monticello package >>> https://code.google.com/p/pharo/issues/detail?id=7605 >>> >>> Issue 7590: Kill MC History Data (>8MB of the image...) >>> https://code.google.com/p/pharo/issues/detail?id=7590 >>> >>> Issue 7553: tons [delaySemaphore wait] process alive in image >>> https://code.google.com/p/pharo/issues/detail?id=7553 >>> (this one for check if it is fixed) >>> >>> Diff information: >>> http://ss3.gemstone.com/ss/Pharo20/NativeBoost-Core-EstebanLorenzano.116.di… >>> http://ss3.gemstone.com/ss/Pharo20/Kernel-EstebanLorenzano.1324.diff >>> >>> >

March 5, 2013

Re: [Pharo-project] [2.0 testing] Export / Import Settings Bug + Fix

by stephane ducasse

Thanks Mike Can you enter a new bug entry else your contribution may get lost? Stef On Mar 5, 2013, at 2:05 PM, "MÃ¼ller, Mike" <mike(a)objektarium.de> wrote: > Hi Pharoers, > > thank you for your time. Here is something you may be interested in: > > Take the latest image or one-click, open settings browser and click on "Export Settings" to persist them. > Then save or not and launch the image again. Exception when reading the preferences from file. > You will further notice that the 2 of the 4 generated startup action files are too large. (> 256kb) > > Reason: > SettingDeclaration>>startupAction stores some setting values as real thick objects on disk. For example, it writes the standard font definitions as Strike Font Instances, which breaks. > > Solution: > In Method "SettingDeclaration>>startupAction" replace "storeOn: s" with "settingStoreOn: s" to write the correct startup action format. > > Error in consequence: > After applying this fix, you will notice another Exception during the Import, the FreeTypeSystemSettings class wants a method called #noFt2Library:, here I suggest to add that missing accessor with no action. Maybe someone can refactor the (FreeTypeSystem)Settings to have a #readOnly setting which must not be saved to disk. > > Attached are my 2 changes, after applying them, my image can read all the settings back from the startup files. The startup files created are much smaller (~8kb). > > This is not exactly clear: "Is every setting materialized from the startup files indeed the original setting?". > That would be an interesting test case. > > Regards, > Mike > > <FreeTypeSystemSettings class-noFt2Library.st><SettingDeclaration-startupAction.st>

March 5, 2013

Re: [Pharo-project] Public FogBugz Access

by Benjamin

That's because each project as to specify that an un logged person can open new cases :) By default I only set _inbox (I was trying a lot of plugins ^^) Ben On Mar 5, 2013, at 5:04 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Mar 5, 2013, at 4:56 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > >> You can already change the project. > > It does not work for me when I am not logged in > > Marcus > >

March 5, 2013