- Pharo-dev - lists.pharo.org

Re: [Pharo-project] SystemChangeNotifier and Traits

by StÃ©phane Ducasse

Eliot We did more than our homework. We have a full code model that is polymorphic with Smalltalk object counterparts. methodReference should be removed because we have much better. Veronica worked at least 4 months on ring and it is good. Stef On Nov 16, 2011, at 10:47 PM, Eliot Miranda wrote: > > > On Wed, Nov 16, 2011 at 1:14 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > + 1 > > and we should remove the old ones and a lot of old abstraction > MethodReference, > PseudoClass, FilePackage, and a lot more > I hope that we will get into that mode soon. > > PseudoClass, FilePackage, may indeed be poor. But IMO MethodReference is central and extremely useful. > > > Stef > > On Nov 16, 2011, at 3:55 PM, Fernando Olivero wrote: > > > Please note that eventually the system is going to be using solely > > System announcements, instead of the old mechanism in place right now. > > > > Did you try hooking up to the SystemAnnouncements? > > > > For examples, check out Nautius. > > > > Fernando > > > > > > > > On Tue, Nov 15, 2011 at 9:02 PM, ezequiel lamonica > > <lamonicaezequiel(a)gmail.com> wrote: > >> Hello again, > >> > >> Now the problem is when I create a class that use Traits, > >> SystemChangeNotifier sends two messages to report this creation: 1st for > >> class added without traits, and 2nd for class modified to use this trait. > >> And this last message has Object as old class instead of ClassForTesting > >> without traits. > >> > >> For example: > >> > >> Object subclass: #ClassForTesting > >> uses: TSortable > >> instanceVariableNames: 'a' > >> classVariableNames: '' > >> poolDictionaries: '' > >> category: 'OOSCM-ClientImageTest' > >> > >> > >> Can I change those messages to use only one message that includes traits? Is > >> not this better? > >> > >> What do you suggest? > >> > >> > >> > >> ----- > >> eze > >> -- > >> View this message in context: http://forum.world.st/SystemChangeNotifier-and-Traits-tp4073962p4073962.html > >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >> > >> > > > > > > > > -- > best, > Eliot >

Nov. 17, 2011

Re: [Pharo-project] Status of ToolBuilder

by StÃ©phane Ducasse

Just to summarize it.ToolBuilder did not support the widgets of Polymorph like tab, drop boxes and others. We removed it (it was discussed at ESUG in Barcelona). We discussed with esteban which was one of the few users. Now there is no tool builder in pharo. Toolbuilder was nice to get a minimal support for a limited set of widgets but it hampered new UI construction. We need to have better way to build and reuse widget logic. Lukas about the glue (and the spec) we will see. Right now we are trying to understand what we want. Ben will clean his 5 classes code so that we can think together. Stef > I was kind of surprised that ToolBuilder is still part of Pharo. > > Are there any users? Are there any plans to update it to match the > version of Squeak? Is it encouraged to build UIs with ToolBuilder? > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >

Nov. 17, 2011

Re: [Pharo-project] SystemChangeNotifier and Traits

by Eliot Miranda

On Wed, Nov 16, 2011 at 8:44 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 16 November 2011 23:47, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > > > On Wed, Nov 16, 2011 at 1:14 PM, StÃ©phane Ducasse > > <stephane.ducasse(a)inria.fr> wrote: > >> > >> + 1 > >> > >> and we should remove the old ones and a lot of old abstraction > >> MethodReference, > >> PseudoClass, FilePackage, and a lot more > >> I hope that we will get into that mode soon. > > > > PseudoClass, FilePackage, may indeed be poor. But IMO MethodReference > is > > central and extremely useful. > > Yes. There's already a replacement for it in Ring model. > But the name is important. I don't want to have to rewrite everything because the name changes. If the name stays the same then is this a replacement? > > >> > >> Stef > >> > >> On Nov 16, 2011, at 3:55 PM, Fernando Olivero wrote: > >> > >> > Please note that eventually the system is going to be using solely > >> > System announcements, instead of the old mechanism in place right now. > >> > > >> > Did you try hooking up to the SystemAnnouncements? > >> > > >> > For examples, check out Nautius. > >> > > >> > Fernando > >> > > >> > > >> > > >> > On Tue, Nov 15, 2011 at 9:02 PM, ezequiel lamonica > >> > <lamonicaezequiel(a)gmail.com> wrote: > >> >> Hello again, > >> >> > >> >> Now the problem is when I create a class that use Traits, > >> >> SystemChangeNotifier sends two messages to report this creation: 1st > >> >> for > >> >> class added without traits, and 2nd for class modified to use this > >> >> trait. > >> >> And this last message has Object as old class instead of > >> >> ClassForTesting > >> >> without traits. > >> >> > >> >> For example: > >> >> > >> >> Object subclass: #ClassForTesting > >> >> uses: TSortable > >> >> instanceVariableNames: 'a' > >> >> classVariableNames: '' > >> >> poolDictionaries: '' > >> >> category: 'OOSCM-ClientImageTest' > >> >> > >> >> > >> >> Can I change those messages to use only one message that includes > >> >> traits? Is > >> >> not this better? > >> >> > >> >> What do you suggest? > >> >> > >> >> > >> >> > >> >> ----- > >> >> eze > >> >> -- > >> >> View this message in context: > >> >> > http://forum.world.st/SystemChangeNotifier-and-Traits-tp4073962p4073962.html > >> >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >> >> > >> >> > >> > > >> > >> > > > > > > > > -- > > best, > > Eliot > > > > > > -- > Best regards, > Igor Stasenko. > > -- best, Eliot

Nov. 17, 2011

Re: [Pharo-project] OpenGL in Pharo?

by Javier PimÃ¡s

We are advancing on making OpenGL work with NativeBoost right now. If you have to write an app that uses OpenGL now, I would strongly recommend you to use NBOpenGL. It's already working on Windows, and we are fixing the missing stuff to make it work on the other platforms. As a side effect, we are developing a base FFI library covering the windowing systems. I started today wrapping XLib and it's already working! here is a screenshot. Of course, it lacks asynchronous calls, but that's only for now. We are also writing a chapter in pharo by example to make it easier for everybody. Cheers, Javier. On Thu, Nov 17, 2011 at 11:32 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 17 November 2011 11:22, Alexandre Bergel <alexandre.bergel(a)me.com> > wrote: > > Igor is working on it i've heard. I am also waiting for it > > > > NativeBoost bindings for OpenGL working fine under Windows. > On Macs and Linux there still missing platform-specific glue code to > initialize context. > I started Mac implementation recently, but i didn't finished it. > Since there are increasing interest, i will try to finish it in nearest > days. > > > > Alexandre > > > > > > On 17 Nov 2011, at 04:52, Michele Lanza <michele.lanza(a)usi.ch> wrote: > > > >> Dear all, > >> I wanted to ask whether there are some news I missed with respect to > having a decent OpenGL framework in Pharo. I checked the following page: > >> > >> > http://book.pharo-project.org/book/LanguageAndLibraries/3DGraphicsAndOpenGL/ > >> > >> ..but it sounds all a bit outdated and not something I can rely on in > the long run. Ideally there should be something like the Jun framework > (available for VisualWorks), but when I met the Jun maker at ICSE and I > asked him whether there were any plans of porting Jun to Pharo he told me > that it was not in their plans. Long talk, short sense: Is anyone working > on OpenGL for Pharo? > >> > >> Cheers > >> > >> Michele > > > > > > > > -- > Best regards, > Igor Stasenko. > > -- Lic. Javier PimÃ¡s Ciudad de Buenos Aires

Nov. 17, 2011

Re: [Pharo-project] [squeak-dev] The SmalltalkHub demo is online!

by Mariano Martinez Peck

On Wed, Nov 16, 2011 at 6:16 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > mariano > > I know you are on holidays, but this one is a quite connected holidays :) > but what is finally the solution to support migration of fuel serialized > objects to new format (the discussion with philippe). > > Martin has sent an email to such thread explaining the most basic solution we could come with. He explicitly asked in such mail for feedback or answers. Noone answered. I copy paste here his answer: " *Hi* * * *I followed with interest the discussion but without many interventions. I want to explain an idea I have for supporting backward-compatibility without neither stabilizing the format nor getting the current code dirty. Maybe it's a bit crazy but I think it can be a practical solution. I would like to know your opinions. * * * * * *We can offer:* * * *- Maintain a *compatibility package* for each released version, that can co-exist in the same image. For example Fuel1_5, Fuel1_6, etc. Obviously, the current version always has the nice clean name (Fuel).* * * * - Provide a facade that works like "Fuel load: aFile asOfVersion: '1.4'" who interacts with the compatibility packages. To generate each *compatibility package*, we rename several elements of the original Fuel released package, this way: * Extension methods: Append at beggining of each extension method selector a prefix. For example: #fuelAccept: --> #fuel1_6_fuelAccept: * * * Classes: Append to each one some version identifier. For example: FLSerializer --> FLSerializer_1_6 * Methods: Fix each reference to a class or extension method selector THAT BELONGS to the package. For example: "FLSerializer new" --> "FLSerializer_1_6 new". I think it could be not that hard to make such renames automatically with a small tool. **Then, we can simultaneously maintain each *compatibility package* (Fuel1_5, Fuel1_6, etc.) when Pharo evolves:* * * * * *Our Jenkins will run tests for all the compatibility Fuel packages. For example... Does Fuel1_7 stop working in Pharo1.5? then (if it's possible) we fix it, save the monticello version and mark it in our ConfigurationOfFuel as "this is the stable monticello version of fuel 1.7 in pharo 1.5".* * * * * * * *Now that I see how many lines I took to explain it, I think it's a bit insane. I hope to read some opinions!* " > Stef > > > On Nov 15, 2011, at 9:56 PM, Mariano Martinez Peck wrote: > > > > > > > On Tue, Nov 15, 2011 at 4:18 PM, Nicolas Petton < > petton.nicolas(a)gmail.com> wrote: > > Hi guys, > > > > I'm glad to tell you that the demo of SmalltalkHub is online. > > http://www.smalltalkhub.com > > > > Note that this is a demo only (all projects will be deleted at some > > point). > > > > You can follow the SmalltalkHub project here: > > http://smalltalkhub.com/user/NicolasPetton/SmalltalkHub > > > > You can report bugs you encounter on the issue tracker there. > > > > This demo is running on Pharo (the next one will be on GemStone). > > > > The changelog is quite big, but here's some important changes: > > > > - The clone feature has been removed in favor of an inbox per project. > > (later the inbox repository url will be visible in the project overview) > > - RSS feeds for project timelines and user activity > > - Persistency is now pluggable (the current demo uses Fuel to serialize > > the repository) > > > > Nice to hear that. Let us know if we can improve something. > > > > BTW.... one thing I would love but I think you already answered to me > that yes, is the ability to have a ConfigurationOfSmalltalkHub which let me > take a standard Pharo image and execute: ConfigurationOfSmalltalkHab > loadWithFuelPresistency. > > and I can have my own/company/whatever repo running :) > > > > > > - New help system > > - New chronological view of packages > > - More useful commit view > > - The issue tracker has received some love some bugs has been fixed > > - new statistics view > > - Email notifications > > - And of course, many bug and UX fixes > > > > Some features that will appear soon (in random order): > > - Scripting engine to perform actions on projects > > - A diff browser > > - the ability to accept/decline packages committed to the inbox, and > > move/delete packages/versions. > > > > Cheers, > > Nicolas > > > > > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > -- Mariano http://marianopeck.wordpress.com

Nov. 17, 2011

Re: [Pharo-project] how should Pier file structures be serialized with Fuel?

by Yanni Chiu

On 17/11/11 1:27 AM, Martin Dias wrote: > > you can implement : > > YourPRFileProxy >> fuelAfterMaterialization > self become: self proxiedPRFile > Anyway, in next version would be nice to provide a faster way of doing > this, without become. Okay #fuelAfterMaterialization - that's something I didn't know about. I think I can use that to re-arrange the content, without using #become.

Nov. 17, 2011

Re: [Pharo-project] how should Pier file structures be serialized with Fuel?

by Mariano Martinez Peck

On Thu, Nov 17, 2011 at 1:56 AM, Yanni Chiu <yanni(a)rogers.com> wrote: > An earlier version of Fuel did not having the substitution feature. So, I > had custom mapping code to pre-process the structures before passing to > Fuel for serialization, and to post-process the deserialized structures. > The main purpose of the code was to nil out the PUSecurity objects, because > they were linked to too many other Pier objects. > > So you have already solved this one using the substitution hook explained here: http://rmod.lille.inria.fr/web/pier/software/Fuel/Version1.7/Hooks ? > I'm now eliminating the custom mapping code by using Fuel substitution. > The PRFile object was handled by saving the file contents in an instance > variable of the mapping object. I've eliminated the custom mapping object. > Now, how should the file contents be saved/restored, using the substitution > feature? > > Let me see if I understand....PRFile has a reference to a file (on disk). So what you want is to serialize not only the PRFile but also the contents of the file? > I'm thinking of substituting a proxy object, which somehow "becomes" a > PRFile after deserialization. > > Any other suggestions? > > > -- Mariano http://marianopeck.wordpress.com

Nov. 17, 2011

Re: [Pharo-project] how should Pier file structures be serialized with Fuel?

by Mariano Martinez Peck

On Thu, Nov 17, 2011 at 3:27 AM, Martin Dias <tinchodias(a)gmail.com> wrote: > Hello! > > On Thu, Nov 17, 2011 at 1:56 AM, Yanni Chiu <yanni(a)rogers.com> wrote: > >> An earlier version of Fuel did not having the substitution feature. So, I >> had custom mapping code to pre-process the structures before passing to >> Fuel for serialization, and to post-process the deserialized structures. >> The main purpose of the code was to nil out the PUSecurity objects, because >> they were linked to too many other Pier objects. >> >> I'm now eliminating the custom mapping code by using Fuel substitution. >> The PRFile object was handled by saving the file contents in an instance >> variable of the mapping object. I've eliminated the custom mapping object. >> Now, how should the file contents be saved/restored, using the substitution >> feature? >> >> I'm thinking of substituting a proxy object, which somehow "becomes" a >> PRFile after deserialization. >> > > you can implement : > > YourPRFileProxy >> fuelAfterMaterialization > self become: self proxiedPRFile > But how he replace its original PRFile of the input graph with a YourPRFileProxy instance? Wouldn't something like this make sense: PRFile >> fuelAccept: aVisitor ^ aVisitor visitSubstitution: self PRFile >> fuelSubstitution ^ YourPRFIleProxy for: self ? The problem there is that ALL PRFile will be replaced by proxies and maybe that's not what you want. > > Anyway, in next version would be nice to provide a faster way of doing > this, without become. > > >> Any other suggestions? >> >> >> > -- Mariano http://marianopeck.wordpress.com

Nov. 17, 2011

[Pharo-project] DrGeo pre-release 11.12e

by Hilaire Fernandes

>From your latest DrGeo installation, you can upgrade to DrGeo pre-release 11.12e To do so, select in the DrGeo environment menu "update DrGeo", then save the session to make the update permanent. Feedback and bugs reports appreciated before final release in December. I also appreciate from XO users cool comments at the DrGeo activity page http://activities.sugarlabs.org/sugar/addon/4323 Hilaire NEW FEATURES #13607 Mark symbol for segment #13589 Mutuate point feature (in select mode with [Shift] key) -- Education 0.2 -- http://blog.ofset.org/hilaire

Nov. 17, 2011

Re: [Pharo-project] WideString performance

by Henrik Sperre Johansen

On 17.11.2011 11:11, Henrik Sperre Johansen wrote: > On 17.11.2011 10:38, Henrik Sperre Johansen wrote: >> >> The efficiency drain in this example is, as Dennis points out, >> CSVParser adding scanned characters 1 by 1 to the WideString >> representing current value. >> >> Cheers, >> Henry > There is something strange going on with CogVM's though, on an old VM > the CSVParser use about 17 secs on Data.csv, while it's 131 secs on > Cog 2508... > It looks like primitive 61 has a *really* slow path for variable word > classes? > > Cheers, > Henry ... or not. (Cog) ws := WideString new: 100000. char := Character value: 5021. [1 to: 100000 do: [:i | ws at: i put: char]] timeToRun 10 (Interpreter) ws := WideString new: 100000. char := Character value: 5021. [1 to: 100000 do: [:i | ws at: i put: char]] timeToRun 12 Seems it is instead the becomeForward: call, as each token starts streaming to a ByteString, and thus triggers it :/ A quick hack which will work in your case since all wide tokens usually start with russian character, is replacing (in nextValue and nextQuotedValue) String streamContents: with something like: (stream peek charCode > 255 ifTrue: [WideString] ifFalse: [String]) streamContents: I don't see an easy/elegant way to avoid it in the general case though :( Cheers, Henry

Nov. 17, 2011