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

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

[Pharo-project] Default encoding for Linux VM [WAS] Re: [For Testing] RC3 One-Click

by Mariano Martinez Peck

On Sat, Apr 3, 2010 at 1:10 PM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > Hi Marcus. I have been testing a little the one click image and I found the > following things: > > - splash.bmp says release candidate 2. It should be release stable 1.0 or > RC3. > > - There is the __MACOSX folder...should be remove. Remember yemuzip ;) > > - In Linux VM, you pass the parameter -encoding latin1 to the VM. > Shouldn't this be UTF-8 ? I don't know. > > Several months ago, I reported this "problem". Today I saw this issue: http://code.google.com/p/pharo/issues/detail?id=3205 so....should we change to UTF-8 ?? cheers Mariano > - In /Contents/Resources not only is PharoV10.sources but also > SqueakV39.sources. Shouldn't SqueakV39.sources be deleted ? even more it > size 16MB!! > > - The name of the zip of the 1.0 maybe should have a name different > than:Pharo-1.0-10515-rc3dev.zip, for example Pharo-1.0-OneClick. > Notice the OneClick as part of the name > > - In linux there are 2 failing test: > TestIdenting >> testNewLineLeaveSpacesOnOldLine > TestIdenting >> testCR2 > They are not new. I even try to ask help and Laurent too some time ago. I > would like someone to analyze them. If it is a problem of the test, I would > remove them. If there is nothing wrong with the test, I would try to analyze > how to fix it. > > - There is a problem in the tests of RBInternalSpellChecker in Linux and > Windows, when you are not connected to internet. There are 13 errors tests. > The SpellChecker uses the MacOS library, but for Linux and Windows it uses > its own. But...it needs to download the file. Thus, it fails if you are > off-line. The place is in > RBInternalSpellChecker >> downloadData > And of course, self url is ' > http://www.lukas-renggli.ch/smalltalk/rb-spelling.dat'. > As now with Metacello configurations, it is easy to select if you want to > download the tests or not, I would put that file somehow in the image (part > of the test package). The file is 2.1 MB on disk. > But maybe there is a reason not to do this. Lukas ? > > > Cheers > > Mariano > > > > On Fri, Apr 2, 2010 at 11:53 PM, Chris Kassopulo <ckasso(a)sprynet.com>wrote: > >> On Fri, 02 Apr 2010 09:04:58 -0400, Marcus Denker <marcus.denker(a)inria.fr> >> wrote: >> >> >>> Here is a one-click image (for easy starting for newbies). >>> >>> I only tested this under macos, so it needs a testrun on Linux and >>> Windows >>> >>> >>> https://gforge.inria.fr/frs/download.php/26774/Pharo-1.0-10515-rc3dev.zip >>> >>> >> Ubuntu 9.04 >> >> 9177 run, 9155 passes, 20 expected failures, 2 failures, 0 errors, 0 >> unexpected passes >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >

March 18, 2011

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

by pharo＠googlecode.com

Comment #2 on issue 3754 by thereluc...(a)fastmail.fm: Omnibrowser's an extra horizontal scrollbar http://code.google.com/p/pharo/issues/detail?id=3754 i add a screenshot. Attachments: extra_scrollbar.png 47.6 KB

March 18, 2011

[Pharo-project] [call for help] Bugtracker

by Marcus Denker

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

Re: [Pharo-project] Issue 3205 in pharo: monticello's error on Linux

by pharo＠googlecode.com

Updates: Status: Closed Comment #3 on issue 3205 by marcus.d...(a)gmail.com: monticello's error on Linux http://code.google.com/p/pharo/issues/detail?id=3205 (No comment was entered for this change.)

March 18, 2011