November 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] SystemChangeNotifier and Traits

by StÃ©phane Ducasse

RGMethodDefinition. > > 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] * Smalltalk User Group

by StÃ©phane Ducasse

Hi norbert We will organize some sprints and you are welcomed :) I want to see if we can have 3 days coding session with esteban, igor and nicolas :) Stef > Ha ha, > > I was asking that myself earlier in this century. AFAIK there are not that much smalltalkers in Berlin. But Potsdam and the HPI are close. I wanted to create a Berlin user group but now I don't live there anymore (and I helped creating one in cologne instead). But I'm inclined to attend anyway even now I'm closer to Lille than Berlin :) > > good luck, > > Norbert > > Am 17.11.2011 um 12:53 schrieb StÃ©phane Ducasse: > >> >> >> Begin forwarded message: >> >>> From: Johannes Rasche <johannesrasche(a)mac.com> >>> Subject: * Smalltalk User Group >>> Date: November 17, 2011 12:27:15 PM GMT+01:00 >>> To: pharo-project-owner(a)lists.gforge.inria.fr >>> >>> as Sven just announced the Belgian Smalltalk User Group (BSUG) meeting: >>> >>> are there Pharo people in Berlin (I didn't realize it up to now)? >>> >>> It would be great to have a local community with the opportunity for face-to-face exchange >>> and potential cooperation >>> >>> Johannes >>> >>> -- >>> Johannes Rasche Hagelberger Str. 56 10965 Berlin mail johannesrasche(a)mac.com mobile +49 1577 175 04 75 >> >

Nov. 17, 2011

Re: [Pharo-project] OpenGL in Pharo?

by StÃ©phane Ducasse

Hi michele Do not expect something like Jun because this is 10 or 15 years. Now I saw today a cairo graphics displayed on the machine of Javier :). This is an example for the Alien chapter of the new pharo book (quite draft). I hope that I will get somebody will work on a minimal code city for moose based on a opengl solution. Now if people have more cycles it will go faster. I hope igor will release soon the opengl binding for mac. Stef On Nov 17, 2011, at 8:52 AM, Michele Lanza 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

Nov. 17, 2011

Re: [Pharo-project] SystemChangeNotifier and Traits

by Eliot Miranda

On Thu, Nov 17, 2011 at 9:43 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > 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. > Is the name the same? Is the replacement still called MethodReference? > 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 > > > > > -- best, Eliot

Nov. 17, 2011

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

by Yanni Chiu

On 17/11/11 1:44 AM, Lukas Renggli wrote: > Just out of curiosity: Why are PUSecurity linked to too many other > objects? Is there a bug leaking memory? I don't think there's a memory leak. My use case here is to export a subtree of a Pier kernel, for import into another Pier kernel. [Aside - not all subtrees can be meaningfully exported, but I'm still discovering the conditions.] In the course of using Fuel (the very first version released), I found that the resulting file was big, and always the same size, no matter what structure was being exported. Looking at the de-serialized structure, I noticed the PUSecurity decoration had pulled in all the users and groups - something I did not want to be imported into the new kernel. This led me to writing a mapping object that contained only the values to be deserialized and used to reconstruct a PRStructure. Thus, the PUSecurity objects were effectively nil'ed out. Now, after upgrading to the latest Fuel, I'm trying to use the substitution feature to accomplish the same. I ended up having to use: serializer analyzer when: [:x | Array = x class and: [x anySatisfy: [:each | PUSecurity = each class ]]] substituteBy: [:x | x reject: [:each | PUSecurity = each class ]] The obvious substitution of nil for the PUSecurity object ends up putting an unexpected nil object in the children Array. I've just noticed that even with the PUSecurity object being striped before serialization, I'm still seeing that the files are big and the same size. It seems that my mapping strategy was leaving off a lot more than just the PUSecurity object.

Nov. 17, 2011

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