June 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Squeak on iPad (2)

by CÃ©drick BÃ©ler

I just tested etoys on the ipad (Bert version). For those interested, send me an email. I'll try to get a Pharo version on it too. That's already very cool but we need to think about a better way to handle the different events. We need event like n-fingers, pinch in and out, etc... Also, we need to build specific tools. That would be cool to discuss that in Barcelona... My 2 cents, 2010/6/15 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > What I would do > - ask alain for the event hierarchy that he extracted from sophie > (because they are better for handling > a lot of situation and mike redesign them with mulitouch in mind. > - check the new event system that was put in place by mike during > the clean he did. > > Stef > > On Jun 15, 2010, at 8:14 PM, Fernando olivero wrote: > > > The model is still there, see for example PasteUpMorph>>addHand: > aHandMorph. > > > > The challenge is creating and triggering the necessary events from the > vm. > > > > This would be excellent to have in Pharo. > > > > Fernando > > > > > > On Jun 15, 2010, at 5:57 PM, Torsten Bergmann wrote: > > > >> More here: > >> > >> http://croquetweak.blogspot.com/2010/06/squeak-etoys-on-ipad.html > >> > >> "Morphic was designed to handle multiple "hands" (pointing devices) > >> from the beginning" > >> > >> I hope we didnt remove that while cleaning morphic, so Pharo > >> could also be made multitouch-aware. > >> > >> Bye > >> T. > >> > >> -- > >> GMX DSL: Internet-, Telefon- und Handy-Flat ab 19,99 EUR/mtl. > >> Bis zu 150 EUR Startguthaben inklusive! http://portal.gmx.net/de/go/dsl > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- CÃ©drick

June 16, 2010

Re: [Pharo-project] VM - Internet Settings?

by laurent laffont

On Wed, Jun 16, 2010 at 10:49 AM, Geert Claes <geert.wl.claes(a)gmail.com>wrote: > > I would like to gauge how many Pharo-ers think that it would be great to > have > the Network/Internet Settings as part of the VM rather than the Image. I > reckon the network setting are (just like display, sound, mouse and printer > settings) dependent on the computer and environment an image is running on > and not necessarily the image itself. > Here's the trick to set preferences for all images: http://book.pharo-project.org/book/TipsAndTricks/PharoRC Cheers, Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/ -- > View this message in context: > http://forum.world.st/VM-Internet-Settings-tp2257076p2257076.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 16, 2010

Re: [Pharo-project] MC breakage in 1.1

by Julian Fitzell

It used to be that you would lose your commit message - that alone might have been reason enough to save it to the cache first. Given that the previous commit messages are now remembered, I agree it seems less important (as far as I can see anyway). Julian On Wed, Jun 16, 2010 at 7:38 AM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > Ok, I have a question, it is really necessary to create and save a > working copy in the default cache when the Save button is pressed and > there are no valid credentials for the selected repository? Why would > you need to save a new version in a cache even though you don't have > permission to save in the repository you have selected in the first > instance? it seems to me the Save button is saving user intentions to > save in the form of new versions in a cache. It isn't supposed MC > should to cache versions which are truly saved?. > > (I did a funny script to confirm, creating 2000 files for free in > local package-cache :) > | repo wc | > repo := MCHttpRepository location: > 'http://www.squeaksource.com/DependencyWalker' user: '' password: ''. > wc := MCWorkingCopy forPackage: (MCPackage named: 'TestSaveMC1'). > 1 to: 2000 do: [ : i | | v | > Â Â Â Â v := wc newVersionWithName: 'TestSaveMC1-hfm. ' , i asString message: > 'nothing'. > Â Â Â Â [ repo storeVersion: v ] on: Error do: [: ex | ] ] > > I think #canSave could answer <false> if credentials are invalid for > the selected repository, and then nothing is saved in the cache > presumably avoiding the ancestor/working copy mismatch that Julian has > described. > > Also exploring the MCRepositoryGroup I've noted the useCache instVar > is never disabled. This is another way to go. > > Opinions? > > HernÃ¡n > > 2010/6/15 Julian Fitzell <jfitzell(a)gmail.com>: >> The Copy button allows you to copy the version from your cache to >> whatever repository you want. I never used the debugger to fix the >> problem (agreed a debugger is not very nice) but simply went to the MC >> repository list, edited the repository, and then simply used Copy to >> put the version where I wanted. >> >> I'm not saying this is the greatest behaviour ever, but it at least >> allowed you to deal with the problem easily when it occurred. If >> people want to come up with a better behaviour that uses exceptions >> and so on, feel free; all I'm saying is that as far as I'm concerned >> the current behaviour is less helpful than the previous behaviour when >> this (common) error happens. >> >> Julian >> >> On Tue, Jun 15, 2010 at 2:12 AM, HernÃ¡n Morales Durand >> <hernan.morales(a)gmail.com> wrote: >>> Hi Julian, >>> >>> 2010/6/15 Julian Fitzell <jfitzell(a)gmail.com>: >>>> It seems that in Pharo 1.1 MC no longer displays the Version window >>>> after a failed commit attempt (due to missing authentication for >>>> example). As a result, cannot easily resubmit the version after fixing >>>> the credentials. >>>> >>> >>> This is the issue, http://code.google.com/p/pharo/issues/detail?id=2260 >>> >>> please reopen if necessary but in the old version the "Version window" >>> is a pluggable standard window with a MCVersionInspector as model and >>> >>> 1) I saw no button to resubmit the version in this Window. The buttons >>> are : Browse, History, Changes, Load, Merge, Adopt, Copy, Diff >>> 2) A Debugger window was opened and used as an information dialog even >>> when there's nothing to Debug (most failure cases are user errors like >>> missing credentials). The Proceed button was used as Resubmit/Retry >>> after the credentials were corrected. >>> >>> I think a version window should be displayed for a succesful save, not >>> for every failed save attempt (imagine a script or a UI test which >>> fails to save hundreds of packages). Actually #storeVersion: should >>> trigger specific exceptions for every kind of failure so appropiate >>> handlers could be implemented for different scenarios. >>> >>>> In fact, as I look further, it's worse than that. Let's say I had >>>> version 1 and changed two methods. After the failed commit the >>>> following seems to be the situation: >>>> >>>> - The ancestor of my working copy is 2 instead of 1 (confirmed with History) >>>> - The working copy is dirty >>>> - The Changes button shows the same two modified methods that I was >>>> trying to save into 2 >>>> - The diff between 1 and 2 shows the two modified methods >>>> - The diff between 2 and my image (as selected from the History >>>> window) shows no changes >>> >>> This is because "2" should not be created. If a copy cannot be saved >>> then there is no reason to increment the version number with the >>> failed attempt. May deserve another issue entry? >>> >>> Please comment I would like to read opinions on this. >>> >>> HernÃ¡n >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 16, 2010

[Pharo-project] VM - Internet Settings?

by Geert Claes

I would like to gauge how many Pharo-ers think that it would be great to have the Network/Internet Settings as part of the VM rather than the Image. I reckon the network setting are (just like display, sound, mouse and printer settings) dependent on the computer and environment an image is running on and not necessarily the image itself. -- View this message in context: http://forum.world.st/VM-Internet-Settings-tp2257076p2257076.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 16, 2010

Re: [Pharo-project] ConfigurationOfCitezen

by Adrien BARREAU

Hello, I published a new version of ConfigurationOfCitezen. All Citezen can be loaded by evaluating: ConfigurationOfCitezen load. Citezen without Seaside, Magritte and Pier, evaluate: ConfigurationOfCitezen loadNoWeb. Adrien. > From: stephane.ducasse(a)inria.fr > Date: Mon, 14 Jun 2010 20:38:05 +0200 > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] ConfigurationOfCitezen > > > > > Hello all, > > > > Maybe I am simply getting confused by reading code from an "old" image, but I am trying to install Citezen. As I read the configuration, it was written in terms of Seaside 2.8, but it looks like 3.0 is being installed. Any ideas? > > > I think that conifguration OfCitezen load lastest dev (as mention in the class comment) > load seaside30 > > > > > I am open to thinking about Seaside 3, but my packages will fail to load due to the configuration changes. So far, all I have found is that I need to "change to the new system" but not much more than that. Perhaps the answer is to comment out the offending #initialize code, load everything, and then worry about how to get them registered. As slick as it is to be able to use Seaside to configure my Seaside apps, I do not want to trust myself on that front; I want them to be secured from the beginning, and temporarily re-configured for development as needed, and then programmatically switched back to secure-or-nothing. > > > > Semi-rhetorical question: should Citezen be loading Seaside? Could/should there be a Citezen-base or something that just reads BibTeX, and then other things that do all of the web-enabled work? All I do with it is parse entries, for which is very valuable. > > indeed we could have a citezen base and a citezen for web > > Damien can reply to you when he reappear from his teaching duties :) > not sure that this is not 8 h per day this week > > Setf > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _________________________________________________________________ Installez gratuitement les nouvelles Emoch'ticones ! http://www.ilovemessenger.fr/emoticones/telecharger-emoticones-emochticones…

June 16, 2010

[Pharo-project] Pushed Cocoa Macintosh VM Squeak 64-32 5.7b1

by John M McIntosh

Squeak 64-32 5.7b1.app.zip Follow the macintosh link from http://www.squeakvm.org/index.html This VM is built using the current (June 15th, 2010 version of VMMaker. This VM is setup to run in 32bit mode with a 32bit image. This VM uses the same plugins (excluding the 32/64bit FT2Plugin) as the 4.2.5b1 VM. I would suggest people take it for a spin, observe menu handling, drawing, sockets, file i/o, drag and drop, cmd line interface & sound. I'd like to move away from the 4.x.x VM to 5.x.x as we move towards getting things running on the iPad. So your help is needed to shake out the bugs. I've set the get Info to say to launch in 32bit Mode. This lets us use the existing plugins. If you really want to flip to 64bit execution mode you can uncheck the box. You will get a dialog at startup, and only the FT2Plugin is certified to work in 64bit mode. Things will run slower but maybe you'll think it's faster... Features: On resize we mangle the window bits (oh well). No doubt some more reading is required. We don't support 8bit video mode, oh likely only 32bit works. -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

June 16, 2010

Re: [Pharo-project] Help menu disappeared [WAS] [ANN] Pharo-1.1-11400-rc1dev10.06.1

by Adrian Lienhard

OK, since there seems no opposition lets change it as proposed. Any taker? Adrian On Jun 15, 2010, at 09:17 , StÃ©phane Ducasse wrote: > > On Jun 14, 2010, at 10:07 PM, Adrian Lienhard wrote: > >> OK, Torsten has some good points (like, why not doing it right now rather than later?)! I took the proposal of Torsten from an earlier mail and tweaked it a bit. This shows the complete world menu including sub menus: >> >> System Browser >> Workspace >> Test Runner >> Monticello Browser >> -------------------- >> Tools >> ... (<-as today) >> Windows >> Collapse all windows >> Expand all windows >> Close top window <<<< we could remove that since you can also press the button >> Close all debuggers >> Send top window to back >> Move window onscreen >> Delete unchanged windows >> System >> About... >> Settings >> -------------- >> VM statistics >> Start profiling all processes >> Start profiling UI >> -------------- >> Start drawing again >> Start stepping again >> -------------- >> Restore display >> Enable halt inspect once >> Help >> Help Browser >> ProfStef Tutorial >> Welcome Workspace >> ---------------- >> Save >> Save as... >> Save and quit >> Quit >> >> >> Note, I inlined the debug menu into System. The reason is that I don't like multiply nested menus and the system menu does not get overly long. Also I deleted "Space left". Maybe other items like "Start stepping again" are also not really useful anymore? Furthermore I moved "Close all debuggers" into the Windows menu. I kept About... in system as I think it has not much to do with Help but more with System. I also changed the labels of some of the items (like Help Browser and ProfStef Tutorial). >> >> Does that look reasonable? >> >> Cheers, >> Adrian >> >> On Jun 14, 2010, at 20:45 , StÃ©phane Ducasse wrote: >> >>> torsten >>> >>> propose a menu redistribution as laurent did so that we arrive to something better. >>> I agree that debug could be in another place than in root. >>> >>> stef >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 16, 2010

Re: [Pharo-project] MC breakage in 1.1

by HernÃ¡n Morales Durand

Ok, I have a question, it is really necessary to create and save a working copy in the default cache when the Save button is pressed and there are no valid credentials for the selected repository? Why would you need to save a new version in a cache even though you don't have permission to save in the repository you have selected in the first instance? it seems to me the Save button is saving user intentions to save in the form of new versions in a cache. It isn't supposed MC should to cache versions which are truly saved?. (I did a funny script to confirm, creating 2000 files for free in local package-cache :) | repo wc | repo := MCHttpRepository location: 'http://www.squeaksource.com/DependencyWalker' user: '' password: ''. wc := MCWorkingCopy forPackage: (MCPackage named: 'TestSaveMC1'). 1 to: 2000 do: [ : i | | v | v := wc newVersionWithName: 'TestSaveMC1-hfm. ' , i asString message: 'nothing'. [ repo storeVersion: v ] on: Error do: [: ex | ] ] I think #canSave could answer <false> if credentials are invalid for the selected repository, and then nothing is saved in the cache presumably avoiding the ancestor/working copy mismatch that Julian has described. Also exploring the MCRepositoryGroup I've noted the useCache instVar is never disabled. This is another way to go. Opinions? HernÃ¡n 2010/6/15 Julian Fitzell <jfitzell(a)gmail.com>: > The Copy button allows you to copy the version from your cache to > whatever repository you want. I never used the debugger to fix the > problem (agreed a debugger is not very nice) but simply went to the MC > repository list, edited the repository, and then simply used Copy to > put the version where I wanted. > > I'm not saying this is the greatest behaviour ever, but it at least > allowed you to deal with the problem easily when it occurred. If > people want to come up with a better behaviour that uses exceptions > and so on, feel free; all I'm saying is that as far as I'm concerned > the current behaviour is less helpful than the previous behaviour when > this (common) error happens. > > Julian > > On Tue, Jun 15, 2010 at 2:12 AM, HernÃ¡n Morales Durand > <hernan.morales(a)gmail.com> wrote: >> Hi Julian, >> >> 2010/6/15 Julian Fitzell <jfitzell(a)gmail.com>: >>> It seems that in Pharo 1.1 MC no longer displays the Version window >>> after a failed commit attempt (due to missing authentication for >>> example). As a result, cannot easily resubmit the version after fixing >>> the credentials. >>> >> >> This is the issue, http://code.google.com/p/pharo/issues/detail?id=2260 >> >> please reopen if necessary but in the old version the "Version window" >> is a pluggable standard window with a MCVersionInspector as model and >> >> 1) I saw no button to resubmit the version in this Window. The buttons >> are : Browse, History, Changes, Load, Merge, Adopt, Copy, Diff >> 2) A Debugger window was opened and used as an information dialog even >> when there's nothing to Debug (most failure cases are user errors like >> missing credentials). The Proceed button was used as Resubmit/Retry >> after the credentials were corrected. >> >> I think a version window should be displayed for a succesful save, not >> for every failed save attempt (imagine a script or a UI test which >> fails to save hundreds of packages). Actually #storeVersion: should >> trigger specific exceptions for every kind of failure so appropiate >> handlers could be implemented for different scenarios. >> >>> In fact, as I look further, it's worse than that. Let's say I had >>> version 1 and changed two methods. After the failed commit the >>> following seems to be the situation: >>> >>> - The ancestor of my working copy is 2 instead of 1 (confirmed with History) >>> - The working copy is dirty >>> - The Changes button shows the same two modified methods that I was >>> trying to save into 2 >>> - The diff between 1 and 2 shows the two modified methods >>> - The diff between 2 and my image (as selected from the History >>> window) shows no changes >> >> This is because "2" should not be created. If a copy cannot be saved >> then there is no reason to increment the version number with the >> failed attempt. May deserve another issue entry? >> >> Please comment I would like to read opinions on this. >> >> HernÃ¡n >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 16, 2010

[Pharo-project] Mac carbon VM goes to 4.2.5beta1U

by John M McIntosh

In order to wrap up some VM fixes that should be pushed into the Squeak 4.x offering I've compiled up a 4.2.5beta1U VM Someone should run the Sunit and smoke test to ensure the VM is sane. Follow the macintosh link from http://www.squeakvm.org/index.html 4.2.5b1 We update to VMMaker-jcg.182, and we make a new FFI plugin using the latest FFI code base (1.7.0) which includes Josh Gargus changes for FFI ExternalForms to support the OpenCL code. -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

June 16, 2010

Re: [Pharo-project] seaside.gemstone.com down - unable to build 1.1-dev

by Dale Henrichs

Simon Denier wrote: > On 11 juin 2010, at 18:52, Dale Henrichs wrote: > >> With each release I do copy the mcz files (source and configs) to http://www.squeaksource.com/metacello, however, at the moment it takes manual intervention to load using the alternate repository. I will spend some time looking at the problem and see if I can make the switchover to the alternate repository more automatic for Metacello itself... > > > That's good to know. Do you do this copy automatically yet? Or is it still manual? Simon, Upon rereading your mail, I think that my first response was off base ... the answer is that it is semi-automatic in that I use the method ConfigurationOfMetacello class>>releaseMetacelloVersion to do all of the copying ... I've used it for the last several releases and since it is running smoothly I will probably add it to the OB-Metacello menu in some form - assuming that that is what you mean by automatic? Dale

June 15, 2010