- Pharo-dev - lists.pharo.org

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

by Igor Stasenko

On 18 March 2011 21:56, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > we need to think about package: > > right now we have a new implementation that is fast, robust and supports well a new generation of tools (glamour, nautilus...). > We are capturing all system events and we would be more or less ready to remove systemNotifier and use Announcement > instead. Cool! > RPackage can live also on the side of PackageInfo for a while but it would be better to have the shortest possible period of co-existence. > > Now one of the problem I see is that we may not have a smooth transition because: > Â Â Â Â - Rpackage does not rely on category tagging matching. > Â Â Â Â - It is simpler to have a mapping from current categories to packages > Â Â Â Â - Now it means that we could load a package in the system and it would be turned into several RPackages > Â Â Â Â so this means that configuration would have to be adapted. > > Â Â Â Â - 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. Is this a conscious decision to have an unique package per each category name, or just a technical limitation? I'd prefer to have a package which can allow an arbitrary category names in future. It may be that tools like browser are not prepared for that.. but not an internal information of package. To my thinking , classes which belong to package could have any category names.. Names should not mean anything.. it is just for humans. > > Now my time is short so I will > Â Â Â Â - probably not implement tags > Â Â Â Â - 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. > As i suggested, we should not rely on category naming in new packages at all. I think we could create an importer which using a legacy logic of making classes belong to some package based on their category name. In future that should be removed. > So if you have suggestion please talk now. > > > Stef > -- Best regards, Igor Stasenko AKA sig.

March 19, 2011

Re: [Pharo-project] [squeak-dev] http://www.mirandabanda.org/files/Cog/VM/VM.r2370/

by Igor Stasenko

On 19 March 2011 01:00, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi All, > Â Â Â I've built new VMs from the latest source. Â If you're a Pharo user you > may want to wait and pick-up one of Igor's VMs. Â These don't yet have a > merged platform source with the standard VM but they do have a number of > bugs fixed. Â See the readme. Â Next task is indeed to merge the plugin set so > that the plugins are compatible with the standard VM. Â As usual I appreciate > y'all pounding on these. I started documenting how things work on Cog wiki. http://code.google.com/p/cog/wiki/AutomatedBuilds 2 All: Please leave a comment(s) if there something is unclear. Also, ask questions. > Enjoy. > Eliot > > > -- Best regards, Igor Stasenko AKA sig.

March 19, 2011

[Pharo-project] http://www.mirandabanda.org/files/Cog/VM/VM.r2370/

by Eliot Miranda

Hi All, I've built new VMs from the latest source. If you're a Pharo user you may want to wait and pick-up one of Igor's VMs. These don't yet have a merged platform source with the standard VM but they do have a number of bugs fixed. See the readme. Next task is indeed to merge the plugin set so that the plugins are compatible with the standard VM. As usual I appreciate y'all pounding on these. Enjoy. Eliot

March 19, 2011

Re: [Pharo-project] Run a Pharo world on WebBrowser.

by Sean P. DeNigris

I would look at Lively Kernel, and maybe email Dan Ingalls. I think he said that he was toying with a Lively Kernel using Smalltalk instead of JS and may even have some code. At the least, it is a great example/proof that you can have a Morphic world in a browser. HTH, Sean -- View this message in context: http://forum.world.st/Run-a-Pharo-world-on-WebBrowser-tp3388632p3388666.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 18, 2011

Re: [Pharo-project] Issue 3754 in pharo: Omnibrowser's an extra horizontal scrollbar

by pharo＠googlecode.com

Comment #4 on issue 3754 by patchi...(a)gmail.com: Omnibrowser's an extra horizontal scrollbar http://code.google.com/p/pharo/issues/detail?id=3754 Thanks, when i originally reported the tracker had no quota. Francisco

March 18, 2011

Re: [Pharo-project] Keymapping development issues

by Tudor Girba

Great. Please keep us posted. Cheers, Doru On 18 Mar 2011, at 18:52, Camillo Bruni wrote: > Ok, I think I will retrofit my tryout on top of the existing work of guille. > camillo > > > On 2011-03-15, at 13:29, Guillermo Polito wrote: > >> Hi! >> >> On Tue, Mar 15, 2011 at 3:18 AM, Tudor Girba <tudor.girba(a)gmail.com> wrote: >> >>> Hi, >>> >>> It seems to me that there are problems due to the merging of Keymapping sub >>> packages into one Keymapping package: >>> - first, camillo seems to publish in Keymapping, while Guillermo publishes >>> in Keymapping-*. This means that one or the other will most certainly lose >>> code. >>> >> >> Actually, we had a couple of problems: >> - I saw the changes made by Camillo, but his version is broken and it was >> not working. >> - I couldn't merge some changes I did because we did not get really >> synchronized at first. >> - We want to change the same things, but we don't like each other's solution >> nor process of development :$. >> >> >>> - second, the version published by Camillo reached >>> Keymapping-CamilloBruni.3, but there already were versions that reached >>> Keymapping-cds.113, which makes Monticello list the new commits by Camillo >>> at the bottom >>> >>> Would it be possible if you two would get synchronized? >>> >>> >>> Also, ConfigurationOfKeymapping is still broken: >>> - loading "(self project version: '1.5') load" still raises the >>> Character>>+ problem due to the initialization >>> - however, loading "(self project version: '1.5-baseline') load" works >>> because it takes the new versions into account >>> >>> Would it be possible to update the configuration? >>> >>> >> I created development version 1.6, which contains a lot of refactorings >> already. It's preety better. I removed the string matching between >> shortcuts, and the ugly selectors to look at the match of a mapping. I'd >> like it to reviewed... >> >> >>> >>> Cheers, >>> Doru >>> >>> >>> >> Cheers, >> Guille >> >> >>> On 14 Mar 2011, at 15:20, Camillo Bruni 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." >>>>> >>>>> >>>> >>>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Some battles are better lost than fought." >>> >>> >>> >>> >>> > > -- www.tudorgirba.com "What we can governs what we wish."

March 18, 2011

[Pharo-project] Run a Pharo world on WebBrowser.

by nullPointer

I thinking do an application for run in desktop, browser and mobile devices. I want know if is REALLY possible run Pharo in a web browser, like a flash/java applet/silverlight application, without problems. Somebody has proved that? How is difficult for the user install the mechanism in browser for run the Pharo image? Thanks for the help. -- View this message in context: http://forum.world.st/Run-a-Pharo-world-on-WebBrowser-tp3388632p3388632.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 18, 2011

Re: [Pharo-project] Issue 3754 in pharo: Omnibrowser's an extra horizontal scrollbar

by pharo＠googlecode.com

Updates: Cc: renggli Comment #3 on issue 3754 by marianopeck: Omnibrowser's an extra horizontal scrollbar http://code.google.com/p/pharo/issues/detail?id=3754 (No comment was entered for this change.)

March 18, 2011

Re: [Pharo-project] [call for help] Bugtracker

by Mariano Martinez Peck

On Fri, Mar 18, 2011 at 11:14 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > There is a bug tracker at > > http://code.google.com/p/pharo/issues/list > > With currently 524 open bug reports. > > With 1.2Core now being released, it would help *a lot* if people who > submitted a report would > check that report in the loght of a released 1.2 and an actively > developing 1.3... > > -> Has the bug already been fixed? Reports that are already fixed > are just incredible wasteful. > -> Does the submitted code need to be updated for 1.3? > -> Did someone ask a question in the meantime? > -> after a long discussion, wouldn't a sumary help to understand > what the > next action is? > > Marcus, once I wrote this: http://www.pharo-project.org/community/issue-tracking but it seems people go directly to google code :( *A lot* of the reports could really need some love from the person who > submitted it orginally. > > We should really think about some scheme to auto-close bug reports. E.g. if > someone asks a question > and the original submitter thinks that it's not even worth to anwer "I > don't know", then a bug report should > be closed after some generous amount of time (e.g. 6 Months), as it's > definitly not important. > > Marcus > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > >

March 18, 2011

Re: [Pharo-project] [call for help] Bugtracker

by Mariano Martinez Peck

On Fri, Mar 18, 2011 at 11:14 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > There is a bug tracker at > > http://code.google.com/p/pharo/issues/list > > With currently 524 open bug reports. > > With 1.2Core now being released, it would help *a lot* if people who > submitted a report would > check that report in the loght of a released 1.2 and an actively > developing 1.3... > > -> Has the bug already been fixed? Reports that are already fixed > are just incredible wasteful. > -> Does the submitted code need to be updated for 1.3? > -> Did someone ask a question in the meantime? > -> after a long discussion, wouldn't a sumary help to understand > what the > next action is? > > *A lot* of the reports could really need some love from the person who > submitted it orginally. > > We should really think about some scheme to auto-close bug reports. E.g. if > someone asks a question > and the original submitter thinks that it's not even worth to anwer "I > don't know", then a bug report should > be closed after some generous amount of time (e.g. 6 Months), as it's > definitly not important. > > Marcus > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > >

March 18, 2011