- Pharo-dev - lists.pharo.org

Re: [Pharo-project] ZeroMQ bindings for Pharo

by Esteban Lorenzano

Hi, We are starting to have a lot of new cool tools to make really enterprise projects. Yes, this needs to be in the book (also with others now absent, like "riak", etc.)... I know not many people maintain it now, which is sad :( ALSO... i think is hard to notice the existence of all that tools, if you are not used to go to book and look... What about adding a link: "Are you going to start a new project? look at the available *tools>http://book.pharo-project.org/book/PharoTools*!" ... somewhere with visibility at pharo-project? Cheers, Esteban El 19/03/2011, a las 9:35a.m., Mariano Martinez Peck escribiÃ³: > People should update > > http://book.pharo-project.org/book/PharoTools/ > > > On Sat, Mar 19, 2011 at 12:31 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Thanks > Keep us aware of your progress. > May be you want to sync with the Ocean people since they are redesigning the network library. > > Stef > > On Mar 19, 2011, at 12:09 PM, Vijay Mathew wrote: > > > Hi all, > > > > I have started working on ZeroMQ bindings for Pharo. > > (ZeroMQ website: http://www.zeromq.org/) > > > > Thanks, > > > > -- Vijay > > > > >

March 19, 2011

Re: [Pharo-project] [ANN] More on Keymappings

by Mariano Martinez Peck

Add keymappings to http://book.pharo-project.org/book/PharoTools/ On Mon, Mar 14, 2011 at 3:20 PM, Camillo Bruni <camillo.bruni(a)inria.fr>wrote: > > On 2011-03-14, at 15:17, Tudor Girba wrote: > > > I saw :). Just two questions: > > - Is the ConfigurationOfKeymapping updated? > > that I pushed to the existing branch > > > - Is it already usable? > not yet, didn't have too much time so far, but the basic tests are working. > the interface will stay the same, but the internals will be much cleaner > and more explicit > > > Cheers, > > Doru > > > > > > On 14 Mar 2011, at 15:15, Camillo Bruni wrote: > > > >> I pushed everying into a single Keymapping package for now. As soon as > there is full functionality we should separate it again. > >> > >> > >> camillo > >> > >> > >> On 2011-03-13, at 22:40, Tudor Girba wrote: > >> > >>> Excellent initiative Camillo! > >>> > >>> Regarding multiple packages: Having multiple packages limits the > conflicts, and saving them individually (for now) it's a small price to pay. > >>> > >>> Cheers, > >>> Doru > >>> > >>> > >>> On 13 Mar 2011, at 22:28, Camillo Bruni wrote: > >>> > >>>> furthermore, lets use a single repos/package (or whatever this is > called in MC). > >>>> I do not like to commit 3 times while refactoring. > >>>> later on we can still split it up so people can actually decide on > what to load. > >>>> > >>>> camillo > >>>> > >>>> On 2011-03-13, at 22:20, Camillo Bruni wrote: > >>>> > >>>>> I can push my changes. but I don't think we should rely too much on > your old code. > >>>>> > >>>>> Im trying to keep the structure of the classes, that was already very > nice IMO. > >>>>> I manly adress the following issues: > >>>>> > >>>>> - use of arrays as result (dedicatet results object) > >>>>> - string to match the shortcuts with the incoming keyboard event > (dropped all of that and started to work on tests to use the shortcuts > directly) > >>>>> - weird event matching directly on morph (simplified and using a > recursive function call now) > >>>>> - horrible unreadable variable names (wherever I started I tried to > put long names to make the code readable) > >>>>> > >>>>> I suggest we can work together on the new code base, since the > interface will stay fairly compatible. > >>>>> > >>>>> camillo > >>>>> > >>>>> On 2011-03-13, at 22:08, Guillermo Polito wrote: > >>>>> > >>>>>> Camillo, I was fixing some tests and going to refactor some ugly > parts of > >>>>>> the package. > >>>>>> > >>>>>> Is there a way to join forces so we don't step into the other work? > >>>>>> > >>>>>> Guille > >>>>>> > >>>>>> On Sun, Mar 13, 2011 at 6:04 PM, Camillo Bruni < > camillo.bruni(a)inria.fr>wrote: > >>>>>> > >>>>>>> I started on the last Lille sprint a complete rewrite of the > Keymapping > >>>>>>> package. As of now it is not yet functional but the growing > test-coverage > >>>>>>> should help to solve this issue. > >>>>>>> > >>>>>>> m(^_-)m > >>>>>>> camillo > >>>>>>> > >>>>>>> On 2011-03-03, at 15:16, Camillo Bruni wrote: > >>>>>>> > >>>>>>>> Right, > >>>>>>>> > >>>>>>>> the stable has a preconditio which limits it to pharo 1.2. > >>>>>>>> Furthermore the initialization code seems to be incompatible as it > uses > >>>>>>> to:do: on Character which is AFAIK not implemented in the core > image Pharo > >>>>>>> 1.3. Hence apply the following changes: > >>>>>>>> > >>>>>>>> KMKeyEvent class >> initializeControlSequences > >>>>>>>> > >>>>>>>> ... > >>>>>>>> $a asciiValue to: $z asciiValue do: [:each | > >>>>>>>> d add: each asCharacter -> (each - $a asciiValue + 1)]. > >>>>>>>> ... > >>>>>>>> > >>>>>>>> then it should work. > >>>>>>>> > >>>>>>>> m(^_-)m > >>>>>>>> camillo > >>>>>>>> > >>>>>>>> > >>>>>>>> On 2011-03-03, at 09:25, Tudor Girba wrote: > >>>>>>>> > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> I am very interested to get Keymapping integrated into Glamour. > Could > >>>>>>> someone help me to load it? > >>>>>>>>> > >>>>>>>>> I tried: > >>>>>>>>> - in Pharo 1.2: > >>>>>>>>> Gofer it squeaksource: 'Keymapping'; package: > >>>>>>> 'ConfigurationOfKeymapping'; load. > >>>>>>>>> (ConfigurationOfKeymapping project version: #stable) load > >>>>>>>>> > >>>>>>>>> - in Pharo 1.3: > >>>>>>>>> Gofer it squeaksource: 'Keymapping'; package: > >>>>>>> 'ConfigurationOfKeymapping'; load. > >>>>>>>>> (ConfigurationOfKeymapping project version: '1.5') load > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Cheers, > >>>>>>>>> Doru > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On 27 Feb 2011, at 09:59, Tudor Girba wrote: > >>>>>>>>> > >>>>>>>>>> I also I cannot load Keymapping 1.5 in Pharo 1.2. I get DNU for > >>>>>>> Character>>+. This is due to an initialization in KMKeyEvent (see > the > >>>>>>> attached debug log). > >>>>>>>>>> > >>>>>>>>>> I did the followings: > >>>>>>>>>> Gofer it > >>>>>>>>>> squeaksource: 'Keymapping'; > >>>>>>>>>> package: 'ConfigurationOfKeymapping'; > >>>>>>>>>> load. > >>>>>>>>>> > >>>>>>>>>> (ConfigurationOfKeymapping project version: #stable) load > >>>>>>>>>> > >>>>>>>>>> Am I missing something, or is this version not supposed to work > in > >>>>>>> Pharo 1.2? > >>>>>>>>>> > >>>>>>>>>> Cheers, > >>>>>>>>>> Doru > >>>>>>>>>> > >>>>>>>>>> <PharoDebug.log> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On 26 Feb 2011, at 21:08, Francisco Ortiz PeÃ±aloza wrote: > >>>>>>>>>> > >>>>>>>>>>> You're telling me that if i do a clean installation of 1.5 it > would > >>>>>>> work? > >>>>>>>>>>> > >>>>>>>>>>> Thanks in advance, > >>>>>>>>>>> Francisco > >>>>>>>>>>> > >>>>>>>>>>> On Sat, Feb 26, 2011 at 3:50 PM, Guillermo Polito > >>>>>>>>>>> <guillermopolito(a)gmail.com> wrote: > >>>>>>>>>>>> Mmm, If you had 1.4 and updated to 1.5, you will have some > problems > >>>>>>> because > >>>>>>>>>>>> I did some refactorings on that... :/. > >>>>>>>>>>>> > >>>>>>>>>>>> On Sat, Feb 26, 2011 at 10:12 AM, Francisco Ortiz PeÃ±aloza > >>>>>>>>>>>> <patchinko(a)gmail.com> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> Guille i was using 1.4 and worked excellent, just tried 1.5 > and on > >>>>>>>>>>>>> every stroke i made i've got a DNU on #realtarget > >>>>>>>>>>>>> > >>>>>>>>>>>>> Installed on last PharoCore 1.2, should i try it on 1.3? > >>>>>>>>>>>>> > >>>>>>>>>>>>> Great work, > >>>>>>>>>>>>> Fran > >>>>>>>>>>>>> > >>>>>>>>>>>>> On Sat, Feb 26, 2011 at 5:29 AM, laurent laffont > >>>>>>>>>>>>> <laurent.laffont(a)gmail.com> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On Sat, Feb 26, 2011 at 5:42 AM, Guillermo Polito > >>>>>>>>>>>>>> <guillermopolito(a)gmail.com> wrote: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> What do we have now? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> - Can provide settings for a set of morphs > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> - Can provide settings for a TextEditors (Smalltalk editor > and > >>>>>>> related) > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> - Settings integration > >>>>>>>>>>>>>>> I added some methods to the Settings Tree Builder in order > to > >>>>>>> avoid > >>>>>>>>>>>>>>> references from the users code. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> - I ran Slint over it and cleaned it a lot more :). ( And > learnt > >>>>>>> that > >>>>>>>>>>>>>>> Slint is there :P ) > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> More info in here: http://guilleel3.blogspot.com/ > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> A new blog, cool ! > >>>>>>>>>>>>>> Can I have Emacs-like keybinding in code editor, to switch > browser, > >>>>>>> ... > >>>>>>>>>>>>>> ? > >>>>>>>>>>>>>> Laurent. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Guille > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> -- > >>>>>>>>>> www.tudorgirba.com > >>>>>>>>>> > >>>>>>>>>> "Every thing has its own flow." > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> www.tudorgirba.com > >>>>>>>>> > >>>>>>>>> "Every thing should have the right to be different." > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> -- > >>> www.tudorgirba.com > >>> > >>> "Value is always contextual." > >>> > >>> > >>> > >>> > >> > >> > > > > -- > > www.tudorgirba.com > > > > "If you interrupt the barber while he is cutting your hair, > > you will end up with a messy haircut." > > > > > > >

March 19, 2011

Re: [Pharo-project] [Pharo-users] Riak Interface for Pharo Smalltalk

by Mariano Martinez Peck

You should update http://book.pharo-project.org/book/PharoTools/ for both, zinc and riak binding otherwise, people forget or never read this email On Tue, Mar 15, 2011 at 10:48 AM, Sven Van Caekenberghe <sven(a)beta9.be>wrote: > > On 14 Mar 2011, at 22:59, Runar Jordahl wrote: > > > I have published the first beta version of a Pharo Smalltalk interface > > to Bashoâs key-value database âRiakâ: > > http://blog.epigent.com/2011/03/riak-interface-for-pharo-smalltalk.html > > > > Regards > > Runar Jordahl > > http://blog.epigent.com/ > > Pretty cool! > > Do you have anything to tell about performance ? > Are you satisfied ? > > Sven > > PS: It is also good to see that you are using Zinc HTTP Components ;-) > > > >

March 19, 2011

Re: [Pharo-project] ZeroMQ bindings for Pharo

by Mariano Martinez Peck

People should update http://book.pharo-project.org/book/PharoTools/ On Sat, Mar 19, 2011 at 12:31 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > Thanks > Keep us aware of your progress. > May be you want to sync with the Ocean people since they are redesigning > the network library. > > Stef > > On Mar 19, 2011, at 12:09 PM, Vijay Mathew wrote: > > > Hi all, > > > > I have started working on ZeroMQ bindings for Pharo. > > (ZeroMQ website: http://www.zeromq.org/) > > > > Thanks, > > > > -- Vijay > > > > >

March 19, 2011

Re: [Pharo-project] ZeroMQ bindings for Pharo

by Alexandre Bergel

I do not know this socket library, but telling us about your plan to work on is important to avoid effort redundancy which often leads to frustration. Alexandre On 19 Mar 2011, at 07:09, Vijay Mathew wrote: > Hi all, > > I have started working on ZeroMQ bindings for Pharo. > (ZeroMQ website: http://www.zeromq.org/) > > Thanks, > > -- Vijay > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 19, 2011

Re: [Pharo-project] need your attention: Package

by StÃ©phane Ducasse

I have another problem is: imagine we do not match category to package so this means that users will have to add explicitly their categories to the package So I load Foo I get the contents of Foo and Foo-B categories into RPackage Foo. I save Foo and it save the classes in Foo and Foo-B (categories are not considered just rpackage contents) Now I add a category Foo-C (because the browser let me do it) -> may be system should ask me: do you want to add to the Foo RPackage? -> may be I should do it explicitly Better is that we have a browser only showing RPackages Then what happen if I add a new class Zork in Foo-C The class category will be Foo-C and again does the system has to check in which package it should put the class? How do I map Zork class? -> explicitly? -> What happens if I do it via a browser only showing classes and categories? So the mapping Category to package is not that bad else we will have to check *****ALL***** the time if a class should be put in a package or not and compare category with package names. And we will have all the crap of matching with sub subc.... most specific categories.... So I would like to community to react to this mail because this is important and people will get frustrated after. I think that a one to one mapping to category is a good idea. + having a browser just showing packages would be good. Then we can after have a browser that show categories as tags and sort the classes accordingly. So people please thing a bit because I want to make progress and losing my time is boring. Stef

March 19, 2011

Re: [Pharo-project] Refactoring Browser Enhancements

by StÃ©phane Ducasse

fixed now and published in DirtyExperiments. Stef On Mar 19, 2011, at 9:31 AM, StÃ©phane Ducasse wrote: > Hi benjamin > > I published a new package (to revert the dependencies) in DirtyExperiments > and a fixed the points raised by lukas. I added also some comments. > I should fix > > testEnvironmentWrapper > | printString wrapper | > printString := BrowserEnvironment new referencesTo: #printString. > wrapper := BrowserEnvironmentWrapper onEnvironment: printString. > self assert: wrapper numberSelectors = printString numberSelectors. > self assert: wrapper numberClasses = printString numberClasses. > self assert: wrapper environment == printString > > Stef > > > On Mar 18, 2011, at 6:39 PM, Benjamin wrote: > >> Hi lukas >> >> with Stef we refactored the Browser environment: >> - now it can be parametrized by a system dictionary >> - we also move selectionIn* to the AST-Core so that Environment can be loaded independently. >> >> Could you integrate the packages in rb? >> There are >> AST-Core >> Refactoring-Critics >> Refactoring-Environment >> Refactoring-Test-Envrionment >> >> In DirtyExperiments on SqueakSource >> >> >> Ben >> >> PS: All the test are green ;) >> >> >> >> >> > >

March 19, 2011

Re: [Pharo-project] ZeroMQ bindings for Pharo

by StÃ©phane Ducasse

Thanks Keep us aware of your progress. May be you want to sync with the Ocean people since they are redesigning the network library. Stef On Mar 19, 2011, at 12:09 PM, Vijay Mathew wrote: > Hi all, > > I have started working on ZeroMQ bindings for Pharo. > (ZeroMQ website: http://www.zeromq.org/) > > Thanks, > > -- Vijay >

March 19, 2011

[Pharo-project] ZeroMQ bindings for Pharo

by Vijay Mathew

Hi all, I have started working on ZeroMQ bindings for Pharo. (ZeroMQ website: http://www.zeromq.org/) Thanks, -- Vijay

March 19, 2011

Re: [Pharo-project] need your attention: Package

by StÃ©phane Ducasse

On Mar 19, 2011, at 11:31 AM, Marcus Denker wrote: > > On Mar 18, 2011, at 9:56 PM, StÃ©phane Ducasse wrote: >> >> - marcus was suggesting me to create a package with the same contents as the one of loaded by MC. >> and to have tags to only represent categories. >> >> Now my time is short so I will >> - probably not implement tags > > Even then, I would vote for mapping one PackageInfo --> one Rpackage. But this is far from simple because you have then to deal with categories matching. I'm trying to see if I can do the following: At load time when I load Foo (ie the package Foo) I map Foo-zork and Foo-cat to Foo (if this is like that in the MC file) Now what is happening if the user create a new category Foo-tt Foo-tt will not be mapped to Foo. So what will happen? So I will try to understand how this is working right now and sync with cyrille. > Categories are not packages, if > we make every category a package we will end up in a big mess (as groups of these would have lots and lots > of dependencies). Already the PackageInfo Packages for Network and Collection (the split into just the class > categories - as- packages) was a mistake, purely driven by speed of MC. I do not think so. Collections should be repackaged. We should repackage the classes. > - check again the implementation of RPackage and in particular the necessary compatibility layer, because I saw some strange >> code. >> - check the MC dependency on method category conventions, because some logic is not defined in the right place >> like overrides in the MC tools and not in the PackageInfo >> - check how a package gets created when loaded: the key question is that there is a problem to rely on categories to >> associate classes to packages because we can end up with overlapping (normally the IDE captures the category renames >> and change the packages accordingly). >> - we should not rely on most-specific-category kind of pattern matching. >> >> So if you have suggestion please talk now. >> >> >> Stef > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > >

March 19, 2011