Re: [Pharo-project] HTML parser (again)
Yes Sean, actually SqueakSource is not really Share Friendly. I wonder if a solution is not having only one repository for all as Monticello seems to handle branches itself. It seems INRIA will start working on this starting from sept. / oct. The automatic inbox is a solution too. But it doesn't mean packages will be integrated mainstream. I like public writable repository. I also wonder why SS is free for private repository, should be paying (so it can pay someone to manage / evolve SqueakSource). Laurent On Thu, Aug 19, 2010 at 12:30 AM, Sean P. DeNigris s...@clipperadams.comwrote: laurent laffont wrote: Sean, could you put your package there ? The wonderful world of Squeak packages... The package I fixed is Todd Blanchard's HTML CSS Validating Parser at http://www.squeaksource.com/htmlcssparser/, not the Scamper HTML from http://www.squeaksource.com/HTML, although both packages are called HTML. However, this is a lovely opportunity to repeat my call for either (or maybe both): * (my favorite) create an inbox for each project on SqS, just like for Squeak and Pharo trunk, so users can choose between the bleeding edge (which would include contributions like this one) or the last officially blessed one; but they would all be in the same place and obvious to find. * or, send an email to all SqS emails saying that if they don't affirm responsibility for their project within X amount of time, the repo will be released to the community i.e. made w/r. I also seem to remember a suggestion at one point to have a list of people that were approved to commit to any repo on SqS. The point is, make it easy to contribute and people will. It is a downer to go through the work of fixing packages, only to put them in my own repo where they may never be found by users, because the repo is read-only and I can't get in touch with the admins. rant Also, adding oneself to each repo is RUBBISH! Even though I usually take the time, I shudder at the thought of all the community fixes that were kept personally or thrown away because it was a hassle to share them. I'm sure many people, like me, just fix things that are broken. This is the whole beauty of a live system that's turtles all the way down - my system's menus are broken, great, I just spend 20 minutes fixing them for every user on the planet vs. the typical X months (if ever) for an OS vendor to get around to a fix /rant Sean -- View this message in context: http://forum.world.st/HTML-parser-again-tp2329387p2330466.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [squeak-dev] Re: HTML parser (again)
That would be really great. As I mentioned before, I am using the CogVM since its release and it is pretty stable (with the exception of crashes due to this socket problem). Is there a place to report possible bugs related to it, or is this mailing list the most appropriate place? Cheers, Doru On 19 Aug 2010, at 01:26, John M McIntosh wrote: I will try to push a CogVM for the mac this weekend, Eliot and I are planing some time then to get this out the door. On 2010-08-18, at 2:05 PM, stephane ducasse wrote: no CogVM is not ready for us. -- = = = = = == John M. McIntosh john...@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http:// www.smalltalkconsulting.com = = = = = == ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com Speaking louder won't make the point worthier. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Help for pharocasts needed: start pharo on Windows (and OSX).
Please please, could someone record the http://pharocasts.blogspot.com/2010/07/pharo-install.html for Windows ? (and OSX would be great too). It's easy, short, I will add subtitles and edit, or you adapt the original subtitles file http://lolgzs.free.fr/pharocasts/original_and_subtitles/start_pharo.ass Cheers, Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/ ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [squeak-dev] Re: HTML parser (again)
On Thu, Aug 19, 2010 at 8:14 AM, Tudor Girba tudor.gi...@gmail.com wrote: That would be really great. As I mentioned before, I am using the CogVM since its release and it is pretty stable (with the exception of crashes due to this socket problem). The socket problem was fixed by henrik. Is there a place to report possible bugs related to it, or is this mailing list the most appropriate place? Eliot said vm-...@lists.squeakfoundation.org was better Cheers, Doru On 19 Aug 2010, at 01:26, John M McIntosh wrote: I will try to push a CogVM for the mac this weekend, Eliot and I are planing some time then to get this out the door. On 2010-08-18, at 2:05 PM, stephane ducasse wrote: no CogVM is not ready for us. -- === John M. McIntosh john...@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com === ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com Speaking louder won't make the point worthier. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Dispatch morphic stepping from window back to model
I agree that we should keep the Model clean :). I think that people used the step to refresh tool and I would really like to avoid that. Now more investigation is needed. On Aug 19, 2010, at 12:12 AM, Torsten Bergmann wrote: See http://code.google.com/p/pharo/issues/list?cursor=2832 for details and please help to discuss if we really need this dispatching of #step methods from the view to the model and the no-op #step methods in Model and MCTool or if we can clean things up a little bit Thanks T. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] CogVM binaries!!! {WAS} Re: [squeak-dev] Re: CogVM on the Mac
On Thu, Aug 19, 2010 at 6:23 AM, Eliot Miranda eliot.mira...@gmail.comwrote: On Wed, Aug 18, 2010 at 8:14 PM, Chris Cunnington smalltalktelevis...@gmail.com wrote: Wow. Have I been looking in the wrong place. I've been downloading trunk build files from svn listed on the squeakvm.org/unix pages, but *sigh* I didn't see the trove of stuff you just pointed out. And there are specific instructions for Mac and Unix builds. This is what I should be looking at. Thank you for pointing there. For folks' convenience I've just put up some unofficial builds (essentially the same builds I use for testing) under http://www.mirandabanda.org/files/Cog/VM HTH Hi Eliot. This, this HELPS A LOT. This is awesome. Seriously. This is really cool. Now we could start to create a Pharo one click based on Cog. Having the binaries will increase people using it, reporting bugs, and submitting fixes. Two questions: 1) why unofficial builds? 2) Do these binaries include the fixes from henrik to avoid the crash tha happens sometime? Thanks Mariano Eliot Chris ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] HTML parser (again)
The problem is how do you control because people published code that I do not like in my breakout project for example. I think that the idea of inbox and community contributors is the way to go, this is open and you can control. In any case as a community we will have to work to identify packages that are of interest. I also suggest that we put two forges in the future one call sandbox where students can publish their trials and exercises and one where the more consequent project are Stef On Aug 19, 2010, at 8:12 AM, laurent laffont wrote: Yes Sean, actually SqueakSource is not really Share Friendly. I wonder if a solution is not having only one repository for all as Monticello seems to handle branches itself. It seems INRIA will start working on this starting from sept. / oct. The automatic inbox is a solution too. But it doesn't mean packages will be integrated mainstream. I like public writable repository. I also wonder why SS is free for private repository, should be paying (so it can pay someone to manage / evolve SqueakSource). Laurent On Thu, Aug 19, 2010 at 12:30 AM, Sean P. DeNigris s...@clipperadams.com wrote: laurent laffont wrote: Sean, could you put your package there ? The wonderful world of Squeak packages... The package I fixed is Todd Blanchard's HTML CSS Validating Parser at http://www.squeaksource.com/htmlcssparser/, not the Scamper HTML from http://www.squeaksource.com/HTML, although both packages are called HTML. However, this is a lovely opportunity to repeat my call for either (or maybe both): * (my favorite) create an inbox for each project on SqS, just like for Squeak and Pharo trunk, so users can choose between the bleeding edge (which would include contributions like this one) or the last officially blessed one; but they would all be in the same place and obvious to find. * or, send an email to all SqS emails saying that if they don't affirm responsibility for their project within X amount of time, the repo will be released to the community i.e. made w/r. I also seem to remember a suggestion at one point to have a list of people that were approved to commit to any repo on SqS. The point is, make it easy to contribute and people will. It is a downer to go through the work of fixing packages, only to put them in my own repo where they may never be found by users, because the repo is read-only and I can't get in touch with the admins. rant Also, adding oneself to each repo is RUBBISH! Even though I usually take the time, I shudder at the thought of all the community fixes that were kept personally or thrown away because it was a hassle to share them. I'm sure many people, like me, just fix things that are broken. This is the whole beauty of a live system that's turtles all the way down - my system's menus are broken, great, I just spend 20 minutes fixing them for every user on the planet vs. the typical X months (if ever) for an OS vendor to get around to a fix /rant Sean -- View this message in context: http://forum.world.st/HTML-parser-again-tp2329387p2330466.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] HTML parser (again)
Yes we should do something. Now the question is how to do something that we can actually implement. I think that we should - start to identify package of interest (quality/topics) - check their license status - check the author and get access - create an inbox Stef laurent laffont wrote: Sean, could you put your package there ? The wonderful world of Squeak packages... The package I fixed is Todd Blanchard's HTML CSS Validating Parser at http://www.squeaksource.com/htmlcssparser/, not the Scamper HTML from http://www.squeaksource.com/HTML, although both packages are called HTML. However, this is a lovely opportunity to repeat my call for either (or maybe both): * (my favorite) create an inbox for each project on SqS, just like for Squeak and Pharo trunk, so users can choose between the bleeding edge (which would include contributions like this one) or the last officially blessed one; but they would all be in the same place and obvious to find. * or, send an email to all SqS emails saying that if they don't affirm responsibility for their project within X amount of time, the repo will be released to the community i.e. made w/r. I also seem to remember a suggestion at one point to have a list of people that were approved to commit to any repo on SqS. The point is, make it easy to contribute and people will. It is a downer to go through the work of fixing packages, only to put them in my own repo where they may never be found by users, because the repo is read-only and I can't get in touch with the admins. rant Also, adding oneself to each repo is RUBBISH! Even though I usually take the time, I shudder at the thought of all the community fixes that were kept personally or thrown away because it was a hassle to share them. I'm sure many people, like me, just fix things that are broken. This is the whole beauty of a live system that's turtles all the way down - my system's menus are broken, great, I just spend 20 minutes fixing them for every user on the planet vs. the typical X months (if ever) for an OS vendor to get around to a fix /rant Sean -- View this message in context: http://forum.world.st/HTML-parser-again-tp2329387p2330466.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] FW: FW: [Seaside] Changes file too big
I took a 1.1 oneClickImage and did Smalltalk condenseChanges and I got no problem. So may be one of the packages you loaded got a problem. Stef On Aug 19, 2010, at 4:57 AM, Robert Sirois wrote: From: watchl...@hotmail.com To: watchl...@hotmail.com Subject: RE: [Pharo-project] FW: [Seaside] Changes file too big Date: Wed, 18 Aug 2010 20:56:37 -0600 Ok... I was running pharo1.0-10505-rc1dev10.01.2. I decided to time machine back to last night, so I only lost a couple hours of work. Somehow Gofer, maybe? added tons of lines of random code to all the methods in the packages I was trying to save out via Monticello and erased all the code I had in them. If you need more information I can pull the image out of time machine from this morning again. Thanks, RS How do I clear the changes or make the max bigger? I would think it would be easy. From: watchl...@hotmail.com To: pharo-project@lists.gforge.inria.fr Subject: RE: [Pharo-project] FW: [Seaside] Changes file too big Date: Wed, 18 Aug 2010 17:22:46 -0600 I can't say for sure until I get home but it was the something dot 505 from a little earlier this year. Thanks, RS Oh, also.. that condenseChanges messed up monticello, too. From: stephane.duca...@inria.fr Date: Wed, 18 Aug 2010 22:58:32 +0200 To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] FW: [Seaside] Changes file too big Oops. Robert can you tell us which version you are using? Stef How do I clear my changes file? Smalltalk condenseChanges. just brings up a PositionalStream error. Thanks, RS ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] We want your photo
don't get under the charm she is a tiger :) Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] CogVM binaries!!! {WAS} Re: [squeak-dev] Re: CogVM on the Mac
That is great, indeed! I was not aware of the socket fixes. Are these in the image or in the VM? Is there an official site for the change set that should be applied to Pharo 1.1? I only know the change set produced by Lukas. Cheers, Doru On 19 Aug 2010, at 09:45, Mariano Martinez Peck wrote: On Thu, Aug 19, 2010 at 6:23 AM, Eliot Miranda eliot.mira...@gmail.com wrote: On Wed, Aug 18, 2010 at 8:14 PM, Chris Cunnington smalltalktelevis...@gmail.com wrote: Wow. Have I been looking in the wrong place. I've been downloading trunk build files from svn listed on the squeakvm.org/unix pages, but *sigh* I didn't see the trove of stuff you just pointed out. And there are specific instructions for Mac and Unix builds. This is what I should be looking at. Thank you for pointing there. For folks' convenience I've just put up some unofficial builds (essentially the same builds I use for testing) under http://www.mirandabanda.org/files/Cog/VM HTH Hi Eliot. This, this HELPS A LOT. This is awesome. Seriously. This is really cool. Now we could start to create a Pharo one click based on Cog. Having the binaries will increase people using it, reporting bugs, and submitting fixes. Two questions: 1) why unofficial builds? 2) Do these binaries include the fixes from henrik to avoid the crash tha happens sometime? Thanks Mariano Eliot Chris ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com Not knowing how to do something is not an argument for how it cannot be done. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] CogVM binaries!!! {WAS} Re: [squeak-dev] Re: CogVM on the Mac
2) Do these binaries include the fixes from henrik to avoid the crash tha happens sometime? Yes, looks like it. Seaside does not immediately crash the VM. Lukas -- Lukas Renggli www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] CogVM binaries!!! {WAS} Re: [squeak-dev] Re: CogVM on the Mac
It also looks like: - OSProcess works well on Mac - the bug related to the window preview in the Watery theme works with the latest VM (I am talking about the preview of the window when hovering over the task bar from Pharo) This is really great! Cheers, Doru On 19 Aug 2010, at 10:57, Lukas Renggli wrote: 2) Do these binaries include the fixes from henrik to avoid the crash tha happens sometime? Yes, looks like it. Seaside does not immediately crash the VM. Lukas -- Lukas Renggli www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com Problem solving should be focused on describing the problem in a way that makes the solution obvious. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] CogVM binaries!!! {WAS} Re: [squeak-dev] Re: CogVM on the Mac
The fixes of henrik where at the VM level. stef On Aug 19, 2010, at 10:34 AM, Tudor Girba wrote: That is great, indeed! I was not aware of the socket fixes. Are these in the image or in the VM? Is there an official site for the change set that should be applied to Pharo 1.1? I only know the change set produced by Lukas. Cheers, Doru On 19 Aug 2010, at 09:45, Mariano Martinez Peck wrote: On Thu, Aug 19, 2010 at 6:23 AM, Eliot Miranda eliot.mira...@gmail.com wrote: On Wed, Aug 18, 2010 at 8:14 PM, Chris Cunnington smalltalktelevis...@gmail.com wrote: Wow. Have I been looking in the wrong place. I've been downloading trunk build files from svn listed on the squeakvm.org/unix pages, but *sigh* I didn't see the trove of stuff you just pointed out. And there are specific instructions for Mac and Unix builds. This is what I should be looking at. Thank you for pointing there. For folks' convenience I've just put up some unofficial builds (essentially the same builds I use for testing) under http://www.mirandabanda.org/files/Cog/VM HTH Hi Eliot. This, this HELPS A LOT. This is awesome. Seriously. This is really cool. Now we could start to create a Pharo one click based on Cog. Having the binaries will increase people using it, reporting bugs, and submitting fixes. Two questions: 1) why unofficial builds? 2) Do these binaries include the fixes from henrik to avoid the crash tha happens sometime? Thanks Mariano Eliot Chris ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com Not knowing how to do something is not an argument for how it cannot be done. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.2] #12099
12099 - - Removed possiblyChanged sent but not implemented methods in NewEditor. Issue 2827:remove all the senders of possiblyChanged - Issue 2829: Improve Watery2 theme drop list appearance. Thanks Gary Chambers. Progress is a step at a time and a lot of time. S. Ducasse the Wise ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [squeak-dev] [ANN] SimpleLogger released
Hi all! I wonder a few things: - Why was SimpleLog deemed hard? The class comment on SLLog etc is pretty straight forward IMHO! - Also SimpleLog has some quite nice features: - A really nice Morph to keep an eye on the logging going on, and to easily filter it etc, although it needs some love for Pharo to compile. - A log to file class with rotation. - Ability to use syslog like Ramon posted, in fact, I think SimpleLog was first with that. I just... wonder why we need to reinvent so many things over and over? Toothpick IMHO was a bit complex, I agree - that was the reason for creating SimpleLog, but hey, SimpleLog is *not* complex. regards, Göran ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [squeak-dev] [ANN] SimpleLogger released
On Aug 19, 2010, at 12:31 PM, Göran Krampe wrote: Hi all! I wonder a few things: - Why was SimpleLog deemed hard? The class comment on SLLog etc is pretty straight forward IMHO! - Also SimpleLog has some quite nice features: - A really nice Morph to keep an eye on the logging going on, and to easily filter it etc, although it needs some love for Pharo to compile. - A log to file class with rotation. - Ability to use syslog like Ramon posted, in fact, I think SimpleLog was first with that. I just... wonder why we need to reinvent so many things over and over? good question. We are trying not in general :) Toothpick IMHO was a bit complex, I agree - that was the reason for creating SimpleLog, but hey, SimpleLog is *not* complex. :) regards, Göran ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Gaucho Progress
Gaucho looks like an interesting system. Too bad the monticello versions don't have comments, making it difficult to track progress. Is there another way to see what's happening? Stephan ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Probably a bug
Hi! Just wanted to mention this, stumbled over it: Character separators asString ...doesn't seem to do give us the right thing :) along the way there. Perhaps Sean stumbled over this too with Todd's HTML parser, that is where I saw the issue at least. So obviously something is different in Pharo these days. regards, Göran ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] DropList/EditableDropList fixes
Indeed. A side effect of supporting Enter on editable drop lists to add items (when in a dialog)... Change TextEntryDialogWindow newTextEditorMorph Answer a new text entry morph. ^(self newTextEntryFor: self getText: #entryText setText: #entryText: getEnabled: nil help: nil) acceptOnCR: false; selectAll This allows the dialog to process the Enter key rather than the PluggableTextFieldMorph. Regards, Gary (via webmail) From: Stéphane Ducasse stephane.duca...@inria.fr To: Pharo-project@lists.gforge.inria.fr Sent: Wednesday, 18 August, 2010 21:59:46 Subject: Re: [Pharo-project] DropList/EditableDropList fixes :) Gary I noticed a change in behavior with dialog before I enter in an inputdialog was bound with enter and now I have to press enter. Did you notice that too? On Aug 18, 2010, at 7:32 PM, Gary Chambers wrote: Sorry, couldn't resist doing a bit more... http://code.google.com/p/pharo/issues/detail?id=2829 Regards, Gary - Original Message - From: Gary Chambers To: Pharo Development Sent: Tuesday, August 17, 2010 5:30 PM Subject: [Pharo-project] DropList/EditableDropList fixes See http://code.google.com/p/pharo/issues/detail?id=2821 Regards, Gary ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Probably a bug
Maybe try Character separators as: String Nicolas 2010/8/19 Göran Krampe go...@krampe.se: Hi! Just wanted to mention this, stumbled over it: Character separators asString ...doesn't seem to do give us the right thing :) along the way there. Perhaps Sean stumbled over this too with Todd's HTML parser, that is where I saw the issue at least. So obviously something is different in Pharo these days. regards, Göran ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Probably a bug
What would you say the right thing is? Cheers, Henry On Aug 19, 2010, at 1:39 14PM, Göran Krampe wrote: Hi! Just wanted to mention this, stumbled over it: Character separators asString ...doesn't seem to do give us the right thing :) along the way there. Perhaps Sean stumbled over this too with Todd's HTML parser, that is where I saw the issue at least. So obviously something is different in Pharo these days. regards, Göran ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Senders of #haltOnce
I discovered some senders of #haltOnce in Pharo 1.1 morphic code as I was using this functionality to debug my own code. I submitted a fix: http://code.google.com/p/pharo/issues/detail?id=2833 Also I discovered countless senders of #halt and friends in library code and tests. This is really bad for continuous integration and for deploying images, because they open debuggers. All these senders should be changed to throw an error or fail the test in some controllable fashion. Lukas -- Lukas Renggli www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] We want your photo
Laurent, could you put my gravatar picture/link ? 2010/8/17 laurent laffont laurent.laff...@gmail.com: for http://pharo-project.org/community/contributors and a little description of your Pharo usage and / or contributions. Thanks, Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/ ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/ ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] FW: [Seaside] Changes file too big
How do I get the log? RS Date: Wed, 18 Aug 2010 23:00:40 +0200 From: marianop...@gmail.com To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] FW: [Seaside] Changes file too big With condenseCHanges we used to have the problem with Invalid UTF input dected (or something like that), but I don't know a possition error. Provide, VM and image version, and a clean PharoDebug.log. cheers mariano On Wed, Aug 18, 2010 at 10:58 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: Oops. Robert can you tell us which version you are using? Stef How do I clear my changes file? Smalltalk condenseChanges. just brings up a PositionalStream error. Thanks, RS ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] SocketStream enh
Stef, I have been testing your SocketStream code. So far so good. I noticed that if accidentally a SmallInteger versus a CharacterOrByte parameter is used in the method SocketStreamupTo:, the environment goes into a degraded state that persists until the original instance of SocketStream gets closed. For example, no more new Socket connects. After closing the original instance of SocketStream, the environment seems to be back to normal. A simple example for reproducing the bad parameter situation is below. Hope this helps, Luis -=-=- Luis Quijano quij...@panasoft.com -=-=- | hostName portNumber hostIP ss data | hostName := '10.10.10.100'. portNumber := 10001. hostIP := NetNameResolver addressForName: hostName timeout: 20. ss := SocketStream openConnectionToHost: hostIP port: portNumber. Transcript show: '-- Connecting --'; cr; show: 'hostName = ' , hostName; cr; show: 'hostIP = ' , hostIP printString; cr; show: 'portNumber = ' , portNumber printString; cr. data := ss upTo: (Character value: 68). Good parameter data := ss upTo: 68. Bad parameter Transcript show: 'Data received: '; show: data; cr. ss close. Transcript show: '-- Connection Closed --'; cr. data inspect. = At 11:43 AM 8/8/2010, you wrote: Hi lukas and others I will integrate the following SocketStream tests and before I would love to see if this does not impact seaside http://code.google.com/p/pharo/issues/detail?id=2767 Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Senders of #haltOnce
good! Stef On Aug 19, 2010, at 2:02 PM, Lukas Renggli wrote: I discovered some senders of #haltOnce in Pharo 1.1 morphic code as I was using this functionality to debug my own code. I submitted a fix: http://code.google.com/p/pharo/issues/detail?id=2833 Also I discovered countless senders of #halt and friends in library code and tests. This is really bad for continuous integration and for deploying images, because they open debuggers. All these senders should be changed to throw an error or fail the test in some controllable fashion. Lukas -- Lukas Renggli www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Senders of #haltOnce
A time ago I noticed them. And I realized most of them were used to notify error conditions instead of using just #error:. Each halt must be analyzed independently :/ On Thu, Aug 19, 2010 at 9:02 AM, Lukas Renggli reng...@gmail.com wrote: I discovered some senders of #haltOnce in Pharo 1.1 morphic code as I was using this functionality to debug my own code. I submitted a fix: http://code.google.com/p/pharo/issues/detail?id=2833 Also I discovered countless senders of #halt and friends in library code and tests. This is really bad for continuous integration and for deploying images, because they open debuggers. All these senders should be changed to throw an error or fail the test in some controllable fashion. Lukas -- Lukas Renggli www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] FW: [Seaside] Changes file too big
on which os are you? Normally there is a log file just close to your vm or image. On Aug 19, 2010, at 3:03 PM, Robert Sirois wrote: How do I get the log? RS Date: Wed, 18 Aug 2010 23:00:40 +0200 From: marianop...@gmail.com To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] FW: [Seaside] Changes file too big With condenseCHanges we used to have the problem with Invalid UTF input dected (or something like that), but I don't know a possition error. Provide, VM and image version, and a clean PharoDebug.log. cheers mariano On Wed, Aug 18, 2010 at 10:58 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: Oops. Robert can you tell us which version you are using? Stef How do I clear my changes file? Smalltalk condenseChanges. just brings up a PositionalStream error. Thanks, RS ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Probably a bug
On 08/19/2010 02:03 PM, Henrik Johansen wrote: What would you say the right thing is? Well, intuitively I would say that converting an Array of Character instances (say 5 instances) using asString would give me a String of size 5. Also, Character space asString does NOT give me 'Character space' but actually ' '. Having a fallback on printString is of course fine, in Object. But... well, I haven't thought *deeply* on this, but a sequencable collection of Characters should IMHO be able to produce a String, and not a printString so to speak. regards, Göran ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Questions about SRP
Hi folks/Paul. First, sorry for the cross-posting. Let me know if I should ask this in another place. I am interested in SRP and to understand the differences with SmartRefStream, ImageSegment, SIXX, parcels, etc. First I would like to find as much info as possible. Right now I found: http://techsupport.gemstone.com/entries/175881-srp-3-1-007-0 http://sourceforge.net/projects/srp/ http://map.squeak.org/accountbyid/94ec671f-6615-4ece-9ab0-5d4addc3be8d/package/bae4b8c3-210f-48b6-8819-eae30354d021 These seems to be dead: http://www.ccse.kfupm.edu.sa/~sohel/IMPP/references/About+State+Replication+Protocol+(SRP).html http://www.whysmalltalk.com/Smalltalk_Solutions/sts2004/pdf/Baumann.pdf Andclass side methods #documentation is there something else? Now, my questions: 1) Does SRP supports cycles in my subgraph? If true, how do you achieve that? 2) What happens with objects like nil, true, false, or any other object that has to be unique in Smalltalk. I mean, how can I make sure that when I load the subgraph in another image, I won't have duplicates of nil, true, etc ? 3) Does it provide a way to fix problems like having to rehash Set instances or things like that? 4) Does it supports class reshape? suppose I put in the file objects of a certain class and then I load the file in another image where that class has different shape (re-order of instVar, rename, new insVar, etc...). If true, how do you achieve that? 5) Do you handle BlockClosure (or BlockCOntext), MethodCoontext, CompiledMethods and things like that ? Thanks a lot for any hints you can give me. Mariano ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Probably a bug
did you check the senders of asString? Because I would like to assess the cost of changing asString from its printString semantics. Stef On Aug 19, 2010, at 3:09 PM, Göran Krampe wrote: On 08/19/2010 02:03 PM, Henrik Johansen wrote: What would you say the right thing is? Well, intuitively I would say that converting an Array of Character instances (say 5 instances) using asString would give me a String of size 5. Also, Character space asString does NOT give me 'Character space' but actually ' '. Having a fallback on printString is of course fine, in Object. But... well, I haven't thought *deeply* on this, but a sequencable collection of Characters should IMHO be able to produce a String, and not a printString so to speak. regards, Göran ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] FW: [Seaside] Changes file too big
On Thu, Aug 19, 2010 at 3:09 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: on which os are you? Normally there is a log file just close to your vm or image. It is in the same directory where your image is and it is called PharoDebug.log but it is opened as append...thus all erros go there. To report an issue is better to remove it, reproduce again the bug and then you will have a clean PharoDebug.log with only that error. cheers mariano On Aug 19, 2010, at 3:03 PM, Robert Sirois wrote: How do I get the log? RS Date: Wed, 18 Aug 2010 23:00:40 +0200 From: marianop...@gmail.com To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] FW: [Seaside] Changes file too big With condenseCHanges we used to have the problem with Invalid UTF input dected (or something like that), but I don't know a possition error. Provide, VM and image version, and a clean PharoDebug.log. cheers mariano On Wed, Aug 18, 2010 at 10:58 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: Oops. Robert can you tell us which version you are using? Stef How do I clear my changes file? Smalltalk condenseChanges. just brings up a PositionalStream error. Thanks, RS ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] SocketStream enh
Tx I will forward that to squeakers because they may be interested too. On Aug 19, 2010, at 3:04 PM, LUIS E QUIJANO wrote: Stef, I have been testing your SocketStream code. So far so good. I noticed that if accidentally a SmallInteger versus a CharacterOrByte parameter is used in the method SocketStreamupTo:, the environment goes into a degraded state that persists until the original instance of SocketStream gets closed. For example, no more new Socket connects. After closing the original instance of SocketStream, the environment seems to be back to normal. A simple example for reproducing the bad parameter situation is below. Hope this helps, Luis -=-=- Luis Quijano quij...@panasoft.com -=-=- | hostName portNumber hostIP ss data | hostName := '10.10.10.100'. portNumber := 10001. hostIP := NetNameResolver addressForName: hostName timeout: 20. ss := SocketStream openConnectionToHost: hostIP port: portNumber. Transcript show: '-- Connecting --'; cr; show: 'hostName = ' , hostName; cr; show: 'hostIP = ' , hostIP printString; cr; show: 'portNumber = ' , portNumber printString; cr. data := ss upTo: (Character value: 68). Good parameter data := ss upTo: 68. Bad parameter Transcript show: 'Data received: '; show: data; cr. ss close. Transcript show: '-- Connection Closed --'; cr. data inspect. = At 11:43 AM 8/8/2010, you wrote: Hi lukas and others I will integrate the following SocketStream tests and before I would love to see if this does not impact seaside http://code.google.com/p/pharo/issues/detail?id=2767 Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Probably a bug
On Aug 19, 2010, at 3:09 42PM, Göran Krampe wrote: On 08/19/2010 02:03 PM, Henrik Johansen wrote: What would you say the right thing is? Well, intuitively I would say that converting an Array of Character instances (say 5 instances) using asString would give me a String of size 5. Also, Character space asString does NOT give me 'Character space' but actually ' '. Maybe its just me, but I'd rather not have SequenceableCollection asString mean If I contain only elements which may represent characters, return a string containing those, if not, return my printString Having a fallback on printString is of course fine, in Object. But... well, I haven't thought *deeply* on this, but a sequencable collection of Characters should IMHO be able to produce a String regards, Göran And it is, using either collection as: String, or String withAll: collection In both cases you then explicitly specify that this collection will contain only elements which can be converted to a string, rather than have a later reader of the code have to question hmmm, does the use of asString here mean he'll be using the collections printString, or the string with its elements? Cheers, Henry ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] FW: [Seaside] Changes file too big
2010/8/19 Marcus Denker marcus.den...@inria.fr From: Robert Sirois watchl...@hotmail.com Date: August 19, 2010 3:17:56 PM GMT+02:00 To: pharo-project@lists.gforge.inria.fr Subject: RE: [Pharo-project] FW: [Seaside] Changes file too big Mmk, thank you. Pharo: pharo1.0-10505-rc1dev10.01.2.image VM: Squeak 4.2.2beta1U The log file is attached. wierd...are you tryiing to create a class called serhgresh ? it should be uppercase... Serhgresh On Aug 19, 2010, at 3:09 PM, Stéphane Ducasse wrote: on which os are you? Normally there is a log file just close to your vm or image. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Senders of #haltOnce
Yes, but even the haltOnce? They're really annoying, I noticed them too. Maybe we should comment on that bug ticket everytime we notice them. On Thu, Aug 19, 2010 at 10:08 AM, Guillermo Polito guillermopol...@gmail.com wrote: A time ago I noticed them. And I realized most of them were used to notify error conditions instead of using just #error:. Each halt must be analyzed independently :/ On Thu, Aug 19, 2010 at 9:02 AM, Lukas Renggli reng...@gmail.com wrote: I discovered some senders of #haltOnce in Pharo 1.1 morphic code as I was using this functionality to debug my own code. I submitted a fix: http://code.google.com/p/pharo/issues/detail?id=2833 Also I discovered countless senders of #halt and friends in library code and tests. This is really bad for continuous integration and for deploying images, because they open debuggers. All these senders should be changed to throw an error or fail the test in some controllable fashion. Lukas -- Lukas Renggli www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Senders of #haltOnce
Yes, but even the haltOnce? They're really annoying, I noticed them too. Maybe we should comment on that bug ticket everytime we notice them. On Thu, Aug 19, 2010 at 10:08 AM, Guillermo Polito guillermopol...@gmail.com wrote: A time ago I noticed them. And I realized most of them were used to notify error conditions instead of using just #error:. Each halt must be analyzed independently :/ On Thu, Aug 19, 2010 at 9:02 AM, Lukas Renggli reng...@gmail.com wrote: I discovered some senders of #haltOnce in Pharo 1.1 morphic code as I was using this functionality to debug my own code. I submitted a fix: http://code.google.com/p/pharo/issues/detail?id=2833 Also I discovered countless senders of #halt and friends in library code and tests. This is really bad for continuous integration and for deploying images, because they open debuggers. All these senders should be changed to throw an error or fail the test in some controllable fashion. Lukas -- Lukas Renggli www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Senders of #haltOnce
On Aug 19, 2010, at 4:05 52PM, Carla F. Griggio wrote: Yes, but even the haltOnce? They're really annoying, I noticed them too. Maybe we should comment on that bug ticket everytime we notice them. No, those are debugging artifacts accidentally left in :/ In my defense, 50% of them were in code hastily copy-pasted to the list as example code, not submitted as a package :) Cheers, Henry ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] FW: [Seaside] Changes file too big
I can't be responsible for all my code ;) What is the solution by the way? My changes file is up from 9mb last night to 31.5 just this morning already... RS Date: Thu, 19 Aug 2010 16:01:13 +0200 From: marianop...@gmail.com To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] FW: [Seaside] Changes file too big 2010/8/19 Marcus Denker marcus.den...@inria.fr From: Robert Sirois watchl...@hotmail.com Date: August 19, 2010 3:17:56 PM GMT+02:00 To: pharo-project@lists.gforge.inria.fr Subject: RE: [Pharo-project] FW: [Seaside] Changes file too big Mmk, thank you. Pharo: pharo1.0-10505-rc1dev10.01.2.image VM: Squeak 4.2.2beta1U The log file is attached. wierd...are you tryiing to create a class called serhgresh ? it should be uppercase... Serhgresh On Aug 19, 2010, at 3:09 PM, Stéphane Ducasse wrote: on which os are you? Normally there is a log file just close to your vm or image. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Introducing smallUML: a little project to help us document :)
Hi everyone! Well, here I am announcing the resulting project of my GSoC experience during the [your] summer: smallUML, a project to help us building diagrams and sharing them with any package of code. My mentor was Stephane Ducasse and my co-mentor Geert Claes, so thanks to them for the guidance up to now, and also to Fernando Olivero who helped me a lot (hope to do some coding with you at ESUG! :P). You can gofer it: Gofer it squeaksource: 'smallUML'; package: 'ConfigurationOfSmallUML'; load. (Smalltalk at: #ConfigurationOfSmallUML) project latestVersion load. And then open the Diagram Browser of the current little examples evaluating: DiagramDrawingDocumentation openDiagramBrowser . This is beta and I'm still working on it, my work will continue after GSoC's deadline, so of course your welcome to give some feedback and think about what features would you like it to have and if you're confortable with the current features. It would be really nice if this helped to get all Pharo projects more documented, with visual diagrams that help understanding them at a glance. Talking about that... the current features are: - Open a *Diagram Browser* for an existing Category Diagrams Holder (this is a class ment to hold the created diagrams and there should be one per category, for now; you can browse DiagramDrawingDocumentation to see an example) - *Create and edit diagrams* programatically describing them with diagram code (the diagram code it's just a protocol of methods meant to describe diagrams, you can see some diagram code browsing DiagramDrawingDocumentation methods or each Class Box in the Diagram Browser) - Every diagram you build through the Diagram Browser it's saved as diagram code, so you can *share it as code* that will reproduce your diagram :) That means that diagrams can 'travel' along it's package when you commit your changes with Monticello! And then they can be edited by anybody, they're not just a pretty picture. - You can *export* your diagram as a *PNG* picture or you can export it's diagram code as a *workspace*. - Only *Class Diagrams* can be built for now. - Class Boxes of a class diagram can be *dragged* to be easily positioned. Some details that are missing: - It's funny, but I can't center the class boxes title! :P - I tried adding some scrollbars to the whiteboard where you can view your diagrams in the Diagram Browser, but if I did that the drag drop of the class boxes worked funny :( I'll ask about that to you later. On the way: - Tests and documentation, and a screencast showing every feature. - Lots of refactors: as I'm adding more kind of diagrams right now, so I'm doing a lot of refactors to make everything more flexible and improving all the messy code there. - A version of Minimal Connectors for anybody to use if they feel like connecting morphs for another project. - Some usability improvements. - Object diagrams - Sequence diagrams - Your feedback :D So I'd really appreciate if you can give it a try and tell me how you feel about it, I'd like it to be very usable. Cheers! Carla ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Can't file in *.st exports
There's some sort of weird system error when I try to fileIn a *.st file (like a class method). It asks me to CR for a debugger or any key to restart. I ended up having to force quit.This is in the latest 1.1 one-click.Thanks,RS ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Introducing smallUML: a little project to help us document :)
I took a quick look, and it looks quite nice! Here is a bit of feedback: - I would prefer to have the menus for manipulating entities directly on the canvas, and not in the panes below - It looks like the last character from the name of the class gets trimmed - sometimes the last character from the names of the methods appears on the next row - When trying to create a box from existing class, I get DNU when the class does not exist. Here I would expect to have the option of selecting this class from a list, not to know it upfront - I would prefer another notation for interfaces vs. classes. Right now you have two borders on top of each other: solid for those entities that can hold code, and dotted for those that cannot be instantiated. I would prefer to have only one border with different thicknesses or different shades of gray to denote code, and italic text to denote abstractness (for traits and interfaces). I am not sure if it matters, but I have to mention that I tested in on a Pharo 1.1 on a CogVM. Cheers, Doru On 19 Aug 2010, at 16:56, Carla F. Griggio wrote: Hi everyone! Well, here I am announcing the resulting project of my GSoC experience during the [your] summer: smallUML, a project to help us building diagrams and sharing them with any package of code. My mentor was Stephane Ducasse and my co-mentor Geert Claes, so thanks to them for the guidance up to now, and also to Fernando Olivero who helped me a lot (hope to do some coding with you at ESUG! :P). You can gofer it: Gofer it squeaksource: 'smallUML'; package: 'ConfigurationOfSmallUML'; load. (Smalltalk at: #ConfigurationOfSmallUML) project latestVersion load. And then open the Diagram Browser of the current little examples evaluating: DiagramDrawingDocumentation openDiagramBrowser . This is beta and I'm still working on it, my work will continue after GSoC's deadline, so of course your welcome to give some feedback and think about what features would you like it to have and if you're confortable with the current features. It would be really nice if this helped to get all Pharo projects more documented, with visual diagrams that help understanding them at a glance. Talking about that... the current features are: • Open a Diagram Browser for an existing Category Diagrams Holder (this is a class ment to hold the created diagrams and there should be one per category, for now; you can browse DiagramDrawingDocumentation to see an example) • Create and edit diagrams programatically describing them with diagram code (the diagram code it's just a protocol of methods meant to describe diagrams, you can see some diagram code browsing DiagramDrawingDocumentation methods or each Class Box in the Diagram Browser) • Every diagram you build through the Diagram Browser it's saved as diagram code, so you can share it as code that will reproduce your diagram :) That means that diagrams can 'travel' along it's package when you commit your changes with Monticello! And then they can be edited by anybody, they're not just a pretty picture. • You can export your diagram as a PNG picture or you can export it's diagram code as a workspace. • Only Class Diagrams can be built for now. • Class Boxes of a class diagram can be dragged to be easily positioned. Some details that are missing: • It's funny, but I can't center the class boxes title! :P • I tried adding some scrollbars to the whiteboard where you can view your diagrams in the Diagram Browser, but if I did that the drag drop of the class boxes worked funny :( I'll ask about that to you later. On the way: • Tests and documentation, and a screencast showing every feature. • Lots of refactors: as I'm adding more kind of diagrams right now, so I'm doing a lot of refactors to make everything more flexible and improving all the messy code there. • A version of Minimal Connectors for anybody to use if they feel like connecting morphs for another project. • Some usability improvements. • Object diagrams • Sequence diagrams • Your feedback :D So I'd really appreciate if you can give it a try and tell me how you feel about it, I'd like it to be very usable. Cheers! Carla ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com In a world where everything is moving ever faster, one might have better chances to win by moving slower. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Can't file in *.st exports
Pardon me for being blunt, Robert, but we're going to need a bit more to go on than some sort of weird system error. Could you please attach a file that you tried to file in, and maybe a screenshot of the error? It would certainly increase your chances of getting some help ;-) -- Cheers, Peter. On 19 aug 2010, at 17:11, Robert Sirois watchl...@hotmail.com wrote: There's some sort of weird system error when I try to fileIn a *.st file (like a class method). It asks me to CR for a debugger or any key to restart. I ended up having to force quit. This is in the latest 1.1 one-click. Thanks, RS ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Wiki spam experience
Hello all, Are there any tricks to running a wiki and not ending up a directory of Nigerian ecomomic scams and pornography? Is moderation the only way to do it, or can it be more automatic? Bill ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Introducing smallUML: a little project to help us document :)
And some more feedback: - It would be nice to be able to add comments - When creating a new diagram, the new diagram should be selected by default (right now it is not predictable) Cheers, Doru On 19 Aug 2010, at 17:23, Tudor Girba wrote: I took a quick look, and it looks quite nice! Here is a bit of feedback: - I would prefer to have the menus for manipulating entities directly on the canvas, and not in the panes below - It looks like the last character from the name of the class gets trimmed - sometimes the last character from the names of the methods appears on the next row - When trying to create a box from existing class, I get DNU when the class does not exist. Here I would expect to have the option of selecting this class from a list, not to know it upfront - I would prefer another notation for interfaces vs. classes. Right now you have two borders on top of each other: solid for those entities that can hold code, and dotted for those that cannot be instantiated. I would prefer to have only one border with different thicknesses or different shades of gray to denote code, and italic text to denote abstractness (for traits and interfaces). I am not sure if it matters, but I have to mention that I tested in on a Pharo 1.1 on a CogVM. Cheers, Doru On 19 Aug 2010, at 16:56, Carla F. Griggio wrote: Hi everyone! Well, here I am announcing the resulting project of my GSoC experience during the [your] summer: smallUML, a project to help us building diagrams and sharing them with any package of code. My mentor was Stephane Ducasse and my co-mentor Geert Claes, so thanks to them for the guidance up to now, and also to Fernando Olivero who helped me a lot (hope to do some coding with you at ESUG! :P). You can gofer it: Gofer it squeaksource: 'smallUML'; package: 'ConfigurationOfSmallUML'; load. (Smalltalk at: #ConfigurationOfSmallUML) project latestVersion load. And then open the Diagram Browser of the current little examples evaluating: DiagramDrawingDocumentation openDiagramBrowser . This is beta and I'm still working on it, my work will continue after GSoC's deadline, so of course your welcome to give some feedback and think about what features would you like it to have and if you're confortable with the current features. It would be really nice if this helped to get all Pharo projects more documented, with visual diagrams that help understanding them at a glance. Talking about that... the current features are: • Open a Diagram Browser for an existing Category Diagrams Holder (this is a class ment to hold the created diagrams and there should be one per category, for now; you can browse DiagramDrawingDocumentation to see an example) • Create and edit diagrams programatically describing them with diagram code (the diagram code it's just a protocol of methods meant to describe diagrams, you can see some diagram code browsing DiagramDrawingDocumentation methods or each Class Box in the Diagram Browser) • Every diagram you build through the Diagram Browser it's saved as diagram code, so you can share it as code that will reproduce your diagram :) That means that diagrams can 'travel' along it's package when you commit your changes with Monticello! And then they can be edited by anybody, they're not just a pretty picture. • You can export your diagram as a PNG picture or you can export it's diagram code as a workspace. • Only Class Diagrams can be built for now. • Class Boxes of a class diagram can be dragged to be easily positioned. Some details that are missing: • It's funny, but I can't center the class boxes title! :P • I tried adding some scrollbars to the whiteboard where you can view your diagrams in the Diagram Browser, but if I did that the drag drop of the class boxes worked funny :( I'll ask about that to you later. On the way: • Tests and documentation, and a screencast showing every feature. • Lots of refactors: as I'm adding more kind of diagrams right now, so I'm doing a lot of refactors to make everything more flexible and improving all the messy code there. • A version of Minimal Connectors for anybody to use if they feel like connecting morphs for another project. • Some usability improvements. • Object diagrams • Sequence diagrams • Your feedback :D So I'd really appreciate if you can give it a try and tell me how you feel about it, I'd like it to be very usable. Cheers! Carla ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com In a world where everything is moving ever faster, one might have better chances to win by moving slower. -- www.tudorgirba.com It's not what we do that matters most, it's how we do it.
Re: [Pharo-project] Introducing smallUML: a little project to help us document :)
Thanks Doru :D Whoops, I forgot to mention: I developed this project mostly in a Pharo1.1 version but not the last one, and when I tested it in the last 1.1 version I noticed what you said: - It looks like the last character from the name of the class gets trimmed - sometimes the last character from the names of the methods appears on the next row But this is because of NewTextMorphfitToParagraph and it's fixed in Pharo 1.2, so I left it as that until the new Pharo dev version is ready :$ About the other things: - I would prefer to have the menus for manipulating entities directly on the canvas, and not in the panes below Great, I'm planning to do that, and also make the boxes editable, so you can write and modify the text without using the little workspace below, and Mariano suggested me to be able to browse classes from the boxes too. What other features would you like to add specifically? - When trying to create a box from existing class, I get DNU when the class does not exist. Here I would expect to have the option of selecting this class from a list, not to know it upfront Oops, thanks, I'll check that. You can choose an existing class from a list if that class is in the same package your documenting. I didn't do that for any existing class because they would be too many. Do you think of a better option? Maybe adding autocompletion of the class name? - I would prefer another notation for interfaces vs. classes. Right now you have two borders on top of each other: solid for those entities that can hold code, and dotted for those that cannot be instantiated. I would prefer to have only one border with different thicknesses or different shades of gray to denote code, and italic text to denote abstractness (for traits and interfaces). That's interesting and it's the kind of feedback I'm most looking for. I chose dashed lines for things you can't instantiate because that's the convention for interfaces in UML that I use at collage, and I thought of a variant of that for trait boxes. But I'm not 100% sure about the styling I chose. The same applies for arrows and the relationships lines. A little note upside the boxes like trait or interface would work also, although I'm afraid they could overlap with connections :/ I'll think about that, but I'd also like to have more opinions from the (hopefully) future users :) Different colors or shades of gray / black could work, I'd prefer not changing the border thickness between boxes. And I chose underlined italic style for Class Instance Variables, but I'm not sure about that either. The underline convention is for Class Variables, but what about Class Instance Variables? I am not sure if it matters, but I have to mention that I tested in on a Pharo 1.1 on a CogVM. That matters! Haven't tested CogVM yet, so... great :D Cheers, Doru On 19 Aug 2010, at 16:56, Carla F. Griggio wrote: Hi everyone! Well, here I am announcing the resulting project of my GSoC experience during the [your] summer: smallUML, a project to help us building diagrams and sharing them with any package of code. My mentor was Stephane Ducasse and my co-mentor Geert Claes, so thanks to them for the guidance up to now, and also to Fernando Olivero who helped me a lot (hope to do some coding with you at ESUG! :P). You can gofer it: Gofer it squeaksource: 'smallUML'; package: 'ConfigurationOfSmallUML'; load. (Smalltalk at: #ConfigurationOfSmallUML) project latestVersion load. And then open the Diagram Browser of the current little examples evaluating: DiagramDrawingDocumentation openDiagramBrowser . This is beta and I'm still working on it, my work will continue after GSoC's deadline, so of course your welcome to give some feedback and think about what features would you like it to have and if you're confortable with the current features. It would be really nice if this helped to get all Pharo projects more documented, with visual diagrams that help understanding them at a glance. Talking about that... the current features are: • Open a Diagram Browser for an existing Category Diagrams Holder (this is a class ment to hold the created diagrams and there should be one per category, for now; you can browse DiagramDrawingDocumentation to see an example) • Create and edit diagrams programatically describing them with diagram code (the diagram code it's just a protocol of methods meant to describe diagrams, you can see some diagram code browsing DiagramDrawingDocumentation methods or each Class Box in the Diagram Browser) • Every diagram you build through the Diagram Browser it's saved as diagram code, so you can share it as code that will reproduce your diagram :) That means that diagrams can 'travel' along it's package when you commit your changes with Monticello! And then they can be edited by anybody, they're not just a pretty picture. • You can export your diagram as a PNG
Re: [Pharo-project] Introducing smallUML: a little project to help us document :)
On Thu, Aug 19, 2010 at 12:45 PM, Tudor Girba tudor.gi...@gmail.com wrote: And some more feedback: - It would be nice to be able to add comments Comments would be great indeed :) - When creating a new diagram, the new diagram should be selected by default (right now it is not predictable) Whoops, that's right! Thanks! Carla Cheers, Doru On 19 Aug 2010, at 17:23, Tudor Girba wrote: I took a quick look, and it looks quite nice! Here is a bit of feedback: - I would prefer to have the menus for manipulating entities directly on the canvas, and not in the panes below - It looks like the last character from the name of the class gets trimmed - sometimes the last character from the names of the methods appears on the next row - When trying to create a box from existing class, I get DNU when the class does not exist. Here I would expect to have the option of selecting this class from a list, not to know it upfront - I would prefer another notation for interfaces vs. classes. Right now you have two borders on top of each other: solid for those entities that can hold code, and dotted for those that cannot be instantiated. I would prefer to have only one border with different thicknesses or different shades of gray to denote code, and italic text to denote abstractness (for traits and interfaces). I am not sure if it matters, but I have to mention that I tested in on a Pharo 1.1 on a CogVM. Cheers, Doru On 19 Aug 2010, at 16:56, Carla F. Griggio wrote: Hi everyone! Well, here I am announcing the resulting project of my GSoC experience during the [your] summer: smallUML, a project to help us building diagrams and sharing them with any package of code. My mentor was Stephane Ducasse and my co-mentor Geert Claes, so thanks to them for the guidance up to now, and also to Fernando Olivero who helped me a lot (hope to do some coding with you at ESUG! :P). You can gofer it: Gofer it squeaksource: 'smallUML'; package: 'ConfigurationOfSmallUML'; load. (Smalltalk at: #ConfigurationOfSmallUML) project latestVersion load. And then open the Diagram Browser of the current little examples evaluating: DiagramDrawingDocumentation openDiagramBrowser . This is beta and I'm still working on it, my work will continue after GSoC's deadline, so of course your welcome to give some feedback and think about what features would you like it to have and if you're confortable with the current features. It would be really nice if this helped to get all Pharo projects more documented, with visual diagrams that help understanding them at a glance. Talking about that... the current features are: • Open a Diagram Browser for an existing Category Diagrams Holder (this is a class ment to hold the created diagrams and there should be one per category, for now; you can browse DiagramDrawingDocumentation to see an example) • Create and edit diagrams programatically describing them with diagram code (the diagram code it's just a protocol of methods meant to describe diagrams, you can see some diagram code browsing DiagramDrawingDocumentation methods or each Class Box in the Diagram Browser) • Every diagram you build through the Diagram Browser it's saved as diagram code, so you can share it as code that will reproduce your diagram :) That means that diagrams can 'travel' along it's package when you commit your changes with Monticello! And then they can be edited by anybody, they're not just a pretty picture. • You can export your diagram as a PNG picture or you can export it's diagram code as a workspace. • Only Class Diagrams can be built for now. • Class Boxes of a class diagram can be dragged to be easily positioned. Some details that are missing: • It's funny, but I can't center the class boxes title! :P • I tried adding some scrollbars to the whiteboard where you can view your diagrams in the Diagram Browser, but if I did that the drag drop of the class boxes worked funny :( I'll ask about that to you later. On the way: • Tests and documentation, and a screencast showing every feature. • Lots of refactors: as I'm adding more kind of diagrams right now, so I'm doing a lot of refactors to make everything more flexible and improving all the messy code there. • A version of Minimal Connectors for anybody to use if they feel like connecting morphs for another project. • Some usability improvements. • Object diagrams • Sequence diagrams • Your feedback :D So I'd really appreciate if you can give it a try and tell me how you feel about it, I'd like it to be very usable. Cheers! Carla ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com In a world where everything is
Re: [Pharo-project] Introducing smallUML: a little project to help us document :)
CarlaI know you have a wishlist/future planswhy don't you list them here and avoid people re-telling you ideas? :) and of course, several people may be intrested in the future features or ideas ! 2010/8/19 Carla F. Griggio carla.grig...@gmail.com On Thu, Aug 19, 2010 at 12:45 PM, Tudor Girba tudor.gi...@gmail.comwrote: And some more feedback: - It would be nice to be able to add comments Comments would be great indeed :) - When creating a new diagram, the new diagram should be selected by default (right now it is not predictable) Whoops, that's right! Thanks! Carla Cheers, Doru On 19 Aug 2010, at 17:23, Tudor Girba wrote: I took a quick look, and it looks quite nice! Here is a bit of feedback: - I would prefer to have the menus for manipulating entities directly on the canvas, and not in the panes below - It looks like the last character from the name of the class gets trimmed - sometimes the last character from the names of the methods appears on the next row - When trying to create a box from existing class, I get DNU when the class does not exist. Here I would expect to have the option of selecting this class from a list, not to know it upfront - I would prefer another notation for interfaces vs. classes. Right now you have two borders on top of each other: solid for those entities that can hold code, and dotted for those that cannot be instantiated. I would prefer to have only one border with different thicknesses or different shades of gray to denote code, and italic text to denote abstractness (for traits and interfaces). I am not sure if it matters, but I have to mention that I tested in on a Pharo 1.1 on a CogVM. Cheers, Doru On 19 Aug 2010, at 16:56, Carla F. Griggio wrote: Hi everyone! Well, here I am announcing the resulting project of my GSoC experience during the [your] summer: smallUML, a project to help us building diagrams and sharing them with any package of code. My mentor was Stephane Ducasse and my co-mentor Geert Claes, so thanks to them for the guidance up to now, and also to Fernando Olivero who helped me a lot (hope to do some coding with you at ESUG! :P). You can gofer it: Gofer it squeaksource: 'smallUML'; package: 'ConfigurationOfSmallUML'; load. (Smalltalk at: #ConfigurationOfSmallUML) project latestVersion load. And then open the Diagram Browser of the current little examples evaluating: DiagramDrawingDocumentation openDiagramBrowser . This is beta and I'm still working on it, my work will continue after GSoC's deadline, so of course your welcome to give some feedback and think about what features would you like it to have and if you're confortable with the current features. It would be really nice if this helped to get all Pharo projects more documented, with visual diagrams that help understanding them at a glance. Talking about that... the current features are: • Open a Diagram Browser for an existing Category Diagrams Holder (this is a class ment to hold the created diagrams and there should be one per category, for now; you can browse DiagramDrawingDocumentation to see an example) • Create and edit diagrams programatically describing them with diagram code (the diagram code it's just a protocol of methods meant to describe diagrams, you can see some diagram code browsing DiagramDrawingDocumentation methods or each Class Box in the Diagram Browser) • Every diagram you build through the Diagram Browser it's saved as diagram code, so you can share it as code that will reproduce your diagram :) That means that diagrams can 'travel' along it's package when you commit your changes with Monticello! And then they can be edited by anybody, they're not just a pretty picture. • You can export your diagram as a PNG picture or you can export it's diagram code as a workspace. • Only Class Diagrams can be built for now. • Class Boxes of a class diagram can be dragged to be easily positioned. Some details that are missing: • It's funny, but I can't center the class boxes title! :P • I tried adding some scrollbars to the whiteboard where you can view your diagrams in the Diagram Browser, but if I did that the drag drop of the class boxes worked funny :( I'll ask about that to you later. On the way: • Tests and documentation, and a screencast showing every feature. • Lots of refactors: as I'm adding more kind of diagrams right now, so I'm doing a lot of refactors to make everything more flexible and improving all the messy code there. • A version of Minimal Connectors for anybody to use if they feel like connecting morphs for another project. • Some usability improvements. • Object diagrams • Sequence diagrams • Your feedback :D So I'd really appreciate if you can give it a try and tell me how you feel about it, I'd like it to be
Re: [Pharo-project] Wiki spam experience
ehh? what are you talking about? which wiki? On Thu, Aug 19, 2010 at 5:32 PM, Schwab,Wilhelm K bsch...@anest.ufl.eduwrote: Hello all, Are there any tricks to running a wiki and not ending up a directory of Nigerian ecomomic scams and pornography? Is moderation the only way to do it, or can it be more automatic? Bill ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] CogVM binaries!!! {WAS} Re: [squeak-dev] Re: CogVM on the Mac
2010/8/19 Mariano Martinez Peck marianop...@gmail.com On Thu, Aug 19, 2010 at 6:23 AM, Eliot Miranda eliot.mira...@gmail.comwrote: On Wed, Aug 18, 2010 at 8:14 PM, Chris Cunnington smalltalktelevis...@gmail.com wrote: Wow. Have I been looking in the wrong place. I've been downloading trunk build files from svn listed on the squeakvm.org/unix pages, but *sigh* I didn't see the trove of stuff you just pointed out. And there are specific instructions for Mac and Unix builds. This is what I should be looking at. Thank you for pointing there. For folks' convenience I've just put up some unofficial builds (essentially the same builds I use for testing) under http://www.mirandabanda.org/files/Cog/VM HTH Hi Eliot. This, this HELPS A LOT. This is awesome. Seriously. This is really cool. Now we could start to create a Pharo one click based on Cog. Having the binaries will increase people using it, reporting bugs, and submitting fixes. Two questions: 1) why unofficial builds? because these sources are not yet maintained by the Squeak VM builders, Andreas, Ian John, and because the cod is still green (e.g. object as method still crashes the VMs). 2) Do these binaries include the fixes from henrik to avoid the crash tha happens sometime? Yes. They're built from the most up-to-date version of the Cog sources. Thanks Mariano Eliot Chris ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] CogVM binaries!!! {WAS} Re: [squeak-dev] Re: CogVM on the Mac
2010/8/19 Eliot Miranda eliot.mira...@gmail.com 2010/8/19 Mariano Martinez Peck marianop...@gmail.com On Thu, Aug 19, 2010 at 6:23 AM, Eliot Miranda eliot.mira...@gmail.comwrote: On Wed, Aug 18, 2010 at 8:14 PM, Chris Cunnington smalltalktelevis...@gmail.com wrote: Wow. Have I been looking in the wrong place. I've been downloading trunk build files from svn listed on the squeakvm.org/unix pages, but *sigh* I didn't see the trove of stuff you just pointed out. And there are specific instructions for Mac and Unix builds. This is what I should be looking at. Thank you for pointing there. For folks' convenience I've just put up some unofficial builds (essentially the same builds I use for testing) under http://www.mirandabanda.org/files/Cog/VM HTH Hi Eliot. This, this HELPS A LOT. This is awesome. Seriously. This is really cool. Now we could start to create a Pharo one click based on Cog. Having the binaries will increase people using it, reporting bugs, and submitting fixes. Two questions: 1) why unofficial builds? because these sources are not yet maintained by the Squeak VM builders, Andreas, Ian John, I agreee with this :) now i got it and because the cod is still green (e.g. object as method still crashes the VMs). but this would mean unstable, or beta or something but not unofficial ;) that's why I was confused. 2) Do these binaries include the fixes from henrik to avoid the crash tha happens sometime? Yes. They're built from the most up-to-date version of the Cog sources. Excellent!!! :) thanks a lot mariano Thanks Mariano Eliot Chris ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] CogVM binaries!!! {WAS} Re: [squeak-dev] Re: CogVM on the Mac
It seems that object as method support still not here Laurent On Thu, Aug 19, 2010 at 11:12 AM, Tudor Girba tudor.gi...@gmail.com wrote: It also looks like: - OSProcess works well on Mac - the bug related to the window preview in the Watery theme works with the latest VM (I am talking about the preview of the window when hovering over the task bar from Pharo) This is really great! Cheers, Doru On 19 Aug 2010, at 10:57, Lukas Renggli wrote: 2) Do these binaries include the fixes from henrik to avoid the crash tha happens sometime? Yes, looks like it. Seaside does not immediately crash the VM. Lukas -- Lukas Renggli www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com Problem solving should be focused on describing the problem in a way that makes the solution obvious. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] code licenses...was HTML parser (again))
Stéphane Ducasse wrote: Yes we should do something. Now the question is how to do something that we can actually implement. I think that we should - start to identify package of interest (quality/topics) - check their license status - check the author and get access - create an inbox Stef Stef, speaking of licenses...I was thinking that for mcz files, we should have a directory of each mcz file that contains the license statement for the code in that _version_ of the mcz file. Most tools would end up ignoring, but if we started including the license _in_ the mcz file, then license status would be _much clearer_. I also assume that a similar addition to mc2 files could/should be done Dale ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Can't file in *.st exports
Better :-) The attached image is of a stack trace that shows where the error occurs, which is certainly helpful! During the execution of ArrayedCollection#mergeSortFrom:to:by:, the message #clone is sent to an instance of Array, and the message is not understood, which means that there is no method called #clone in the Array class or any of its superclasses. So the question is, why is the message being sent, when no corresponding method exists on the receiver? One possibility is that there is an error in the method where the #clone message is being sent, or that the missing method just hasn't been filed in yet. The next step would probably be to look at the file being filed in, and see what methods it contains. Perhaps it depends on another file that needs to be filed in first? -- Cheers, Peter 2010/8/19 Robert Sirois watchl...@hotmail.com No problem, Pharo's driving me crazy today hehe. It says: *** system error handling failed *** (see attached image). Thanks, RS From: oldmanl...@gmail.com Date: Thu, 19 Aug 2010 17:33:03 +0200 To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Can't file in *.st exports Pardon me for being blunt, Robert, but we're going to need a bit more to go on than some sort of weird system error. Could you please attach a file that you tried to file in, and maybe a screenshot of the error? It would certainly increase your chances of getting some help ;-) -- Cheers, Peter. On 19 aug 2010, at 17:11, Robert Sirois watchl...@hotmail.com wrote: There's some sort of weird system error when I try to fileIn a *.st file (like a class method). It asks me to CR for a debugger or any key to restart. I ended up having to force quit. This is in the latest 1.1 one-click. Thanks, RS ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Wiki spam experience
Any wiki. If you want something more specific, does our Pharo site wiki remain unscarred because we control who can edit it, or is there something to stop me from doing bad things to it if I were so inclined? I am asking on behalf of somone who has had problems with a wider audience. From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck [marianop...@gmail.com] Sent: Thursday, August 19, 2010 11:55 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Wiki spam experience ehh? what are you talking about? which wiki? On Thu, Aug 19, 2010 at 5:32 PM, Schwab,Wilhelm K bsch...@anest.ufl.edumailto:bsch...@anest.ufl.edu wrote: Hello all, Are there any tricks to running a wiki and not ending up a directory of Nigerian ecomomic scams and pornography? Is moderation the only way to do it, or can it be more automatic? Bill ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.frmailto:Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Probably a bug
Göran Krampe wrote: Perhaps Sean stumbled over this too with Todd's HTML parser. I just made some basic syntax fixes and removed underscore assignments. I never executed anything (except class-side initialization)! Sean -- View this message in context: http://forum.world.st/Probably-a-bug-tp2331029p2331589.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Can't file in *.st exports
clone has been removed from Pharo 1.1 in favour of shallowCopy (they behave the same). The removal was a bit zealous, and did not follow any deprecation policy. So it makes it a bit harder to load some packages. But I think lessons are learned: Steph proposed to keep deprecated methods across 2 minor releases. Nicolas 2010/8/19 Peter Hugosson-Miller oldmanl...@gmail.com: Better :-) The attached image is of a stack trace that shows where the error occurs, which is certainly helpful! During the execution of ArrayedCollection#mergeSortFrom:to:by:, the message #clone is sent to an instance of Array, and the message is not understood, which means that there is no method called #clone in the Array class or any of its superclasses. So the question is, why is the message being sent, when no corresponding method exists on the receiver? One possibility is that there is an error in the method where the #clone message is being sent, or that the missing method just hasn't been filed in yet. The next step would probably be to look at the file being filed in, and see what methods it contains. Perhaps it depends on another file that needs to be filed in first? -- Cheers, Peter 2010/8/19 Robert Sirois watchl...@hotmail.com No problem, Pharo's driving me crazy today hehe. It says: *** system error handling failed *** (see attached image). Thanks, RS From: oldmanl...@gmail.com Date: Thu, 19 Aug 2010 17:33:03 +0200 To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Can't file in *.st exports Pardon me for being blunt, Robert, but we're going to need a bit more to go on than some sort of weird system error. Could you please attach a file that you tried to file in, and maybe a screenshot of the error? It would certainly increase your chances of getting some help ;-) -- Cheers, Peter. On 19 aug 2010, at 17:11, Robert Sirois watchl...@hotmail.com wrote: There's some sort of weird system error when I try to fileIn a *.st file (like a class method). It asks me to CR for a debugger or any key to restart. I ended up having to force quit. This is in the latest 1.1 one-click. Thanks, RS ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Can't file in *.st exports
There are three senders of #clone in the 1.1 One-click image, all part of the sound package. (I've uploaded a new version to PharoSound where this is fixed, and #copy occurences replaced with #postCopy implementations instead). ArrayedCollectionmergeSortFrom:to:by uses shallowCopy. I'd check what code you've imported which has changed that. Cheers, Henry On Aug 19, 2010, at 6:49 43PM, Peter Hugosson-Miller wrote: Better :-) The attached image is of a stack trace that shows where the error occurs, which is certainly helpful! During the execution of ArrayedCollection#mergeSortFrom:to:by:, the message #clone is sent to an instance of Array, and the message is not understood, which means that there is no method called #clone in the Array class or any of its superclasses. So the question is, why is the message being sent, when no corresponding method exists on the receiver? One possibility is that there is an error in the method where the #clone message is being sent, or that the missing method just hasn't been filed in yet. The next step would probably be to look at the file being filed in, and see what methods it contains. Perhaps it depends on another file that needs to be filed in first? -- Cheers, Peter 2010/8/19 Robert Sirois watchl...@hotmail.com No problem, Pharo's driving me crazy today hehe. It says: *** system error handling failed *** (see attached image). Thanks, RS From: oldmanl...@gmail.com Date: Thu, 19 Aug 2010 17:33:03 +0200 To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Can't file in *.st exports Pardon me for being blunt, Robert, but we're going to need a bit more to go on than some sort of weird system error. Could you please attach a file that you tried to file in, and maybe a screenshot of the error? It would certainly increase your chances of getting some help ;-) -- Cheers, Peter. On 19 aug 2010, at 17:11, Robert Sirois watchl...@hotmail.com wrote: There's some sort of weird system error when I try to fileIn a *.st file (like a class method). It asks me to CR for a debugger or any key to restart. I ended up having to force quit. This is in the latest 1.1 one-click. Thanks, RS ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] CogVM binaries!!! {WAS} Re: [squeak-dev] Re: CogVM on the Mac
On Aug 19, 2010, at 6:12 36PM, Eliot Miranda wrote: 2010/8/19 Mariano Martinez Peck marianop...@gmail.com 2) Do these binaries include the fixes from henrik to avoid the crash tha happens sometime? Yes. They're built from the most up-to-date version of the Cog sources. Mmmh, if you don't want to update the folder name to reflect the actual svn version, would changing the !README.txt at least be possible? ;) Cheers, Henry___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Working on Pharo 1.2
Ok, here are the two URLs with redirects to the current 1.1 release downloads. http://pharo-project.org/pharo-download/stable http://pharo-project.org/pharo-download/stable-core I've closed #2805. Cheers, Adrian On Aug 16, 2010, at 22:14 , Adrian Lienhard wrote: On Aug 16, 2010, at 21:53 , Lukas Renggli wrote: That's excellent, but is Pharo 1.2 already stable? No, its not stable. I just picked a random link to allow people to test this setup. Sorry for the confusion... Adrian On 16 August 2010 21:51, Adrian Lienhard a...@netstyle.ch wrote: Just as a test, I created the following page that redirects to a Pharo download zip. http://pharo-project.org/pharo-download/stable It redirects with a HTTP 302 response. Does that work for the scripts in use? We would like to keep the files on the existing server and serve them from there. Adrian On Aug 15, 2010, at 16:35 , Adrian Lienhard wrote: We are working on it... or rather, we are discussing how to do it. It's not forgotten. Adrian On Aug 15, 2010, at 14:42 , Sean P. DeNigris wrote: Stéphane Ducasse wrote: send the code :) What is the status of the unique link to stable and trunk discussed at http://forum.world.st/is-there-an-unique-URL-to-the-latest-pharo-core-or-dev-release-td2317894.html#a2317894 ? Having a static url would prevent having to constantly update the URL referenced in the find trunk here message. I created an issue: http://code.google.com/p/pharo/issues/detail?id=2805 Sean -- View this message in context: http://forum.world.st/Working-on-Pharo-1-2-tp2322972p2325897.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] code licenses...was HTML parser (again))
Yes with first class package we could attach the license to the package Now with the work of Carla I would like to resurrect the DrDoc Project so that we get a kind of manifesto = a special class per package that contains the doc and the license. Stef Stéphane Ducasse wrote: Yes we should do something. Now the question is how to do something that we can actually implement. I think that we should - start to identify package of interest (quality/topics) - check their license status - check the author and get access - create an inbox Stef Stef, speaking of licenses...I was thinking that for mcz files, we should have a directory of each mcz file that contains the license statement for the code in that _version_ of the mcz file. Most tools would end up ignoring, but if we started including the license _in_ the mcz file, then license status would be _much clearer_. I also assume that a similar addition to mc2 files could/should be done Dale ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Probably a bug
What would you say the right thing is? Well, intuitively I would say that converting an Array of Character instances (say 5 instances) using asString would give me a String of size 5. Also, Character space asString does NOT give me 'Character space' but actually ' '. Maybe its just me, but I'd rather not have SequenceableCollection asString mean If I contain only elements which may represent characters, return a string containing those, if not, return my printString yes you are not the only one. Thanks I was thinking about that after my post :) Having a fallback on printString is of course fine, in Object. But... well, I haven't thought *deeply* on this, but a sequencable collection of Characters should IMHO be able to produce a String regards, Göran And it is, using either collection as: String, or String withAll: collection In both cases you then explicitly specify that this collection will contain only elements which can be converted to a string, rather than have a later reader of the code have to question hmmm, does the use of asString here mean he'll be using the collections printString, or the string with its elements? I'm curious about the senders of asString, especially to collection. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Working on Pharo 1.2
This is great, thanks a lot. I am using them on the build server now. Lukas On 19 August 2010 21:47, Adrian Lienhard a...@netstyle.ch wrote: Ok, here are the two URLs with redirects to the current 1.1 release downloads. http://pharo-project.org/pharo-download/stable http://pharo-project.org/pharo-download/stable-core I've closed #2805. Cheers, Adrian On Aug 16, 2010, at 22:14 , Adrian Lienhard wrote: On Aug 16, 2010, at 21:53 , Lukas Renggli wrote: That's excellent, but is Pharo 1.2 already stable? No, its not stable. I just picked a random link to allow people to test this setup. Sorry for the confusion... Adrian On 16 August 2010 21:51, Adrian Lienhard a...@netstyle.ch wrote: Just as a test, I created the following page that redirects to a Pharo download zip. http://pharo-project.org/pharo-download/stable It redirects with a HTTP 302 response. Does that work for the scripts in use? We would like to keep the files on the existing server and serve them from there. Adrian On Aug 15, 2010, at 16:35 , Adrian Lienhard wrote: We are working on it... or rather, we are discussing how to do it. It's not forgotten. Adrian On Aug 15, 2010, at 14:42 , Sean P. DeNigris wrote: Stéphane Ducasse wrote: send the code :) What is the status of the unique link to stable and trunk discussed at http://forum.world.st/is-there-an-unique-URL-to-the-latest-pharo-core-or-dev-release-td2317894.html#a2317894 ? Having a static url would prevent having to constantly update the URL referenced in the find trunk here message. I created an issue: http://code.google.com/p/pharo/issues/detail?id=2805 Sean -- View this message in context: http://forum.world.st/Working-on-Pharo-1-2-tp2322972p2325897.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Working on Pharo 1.2
Great!!! Stef On Aug 19, 2010, at 9:47 PM, Adrian Lienhard wrote: Ok, here are the two URLs with redirects to the current 1.1 release downloads. http://pharo-project.org/pharo-download/stable http://pharo-project.org/pharo-download/stable-core I've closed #2805. Cheers, Adrian On Aug 16, 2010, at 22:14 , Adrian Lienhard wrote: On Aug 16, 2010, at 21:53 , Lukas Renggli wrote: That's excellent, but is Pharo 1.2 already stable? No, its not stable. I just picked a random link to allow people to test this setup. Sorry for the confusion... Adrian On 16 August 2010 21:51, Adrian Lienhard a...@netstyle.ch wrote: Just as a test, I created the following page that redirects to a Pharo download zip. http://pharo-project.org/pharo-download/stable It redirects with a HTTP 302 response. Does that work for the scripts in use? We would like to keep the files on the existing server and serve them from there. Adrian On Aug 15, 2010, at 16:35 , Adrian Lienhard wrote: We are working on it... or rather, we are discussing how to do it. It's not forgotten. Adrian On Aug 15, 2010, at 14:42 , Sean P. DeNigris wrote: Stéphane Ducasse wrote: send the code :) What is the status of the unique link to stable and trunk discussed at http://forum.world.st/is-there-an-unique-URL-to-the-latest-pharo-core-or-dev-release-td2317894.html#a2317894 ? Having a static url would prevent having to constantly update the URL referenced in the find trunk here message. I created an issue: http://code.google.com/p/pharo/issues/detail?id=2805 Sean -- View this message in context: http://forum.world.st/Working-on-Pharo-1-2-tp2322972p2325897.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Can't file in *.st exports
Thanks henrik, you uploaded the code in the pharoNonCore repo? Stef On Aug 19, 2010, at 8:20 PM, Henrik Johansen wrote: There are three senders of #clone in the 1.1 One-click image, all part of the sound package. (I've uploaded a new version to PharoSound where this is fixed, and #copy occurences replaced with #postCopy implementations instead). ArrayedCollectionmergeSortFrom:to:by uses shallowCopy. I'd check what code you've imported which has changed that. Cheers, Henry On Aug 19, 2010, at 6:49 43PM, Peter Hugosson-Miller wrote: Better :-) The attached image is of a stack trace that shows where the error occurs, which is certainly helpful! During the execution of ArrayedCollection#mergeSortFrom:to:by:, the message #clone is sent to an instance of Array, and the message is not understood, which means that there is no method called #clone in the Array class or any of its superclasses. So the question is, why is the message being sent, when no corresponding method exists on the receiver? One possibility is that there is an error in the method where the #clone message is being sent, or that the missing method just hasn't been filed in yet. The next step would probably be to look at the file being filed in, and see what methods it contains. Perhaps it depends on another file that needs to be filed in first? -- Cheers, Peter 2010/8/19 Robert Sirois watchl...@hotmail.com No problem, Pharo's driving me crazy today hehe. It says: *** system error handling failed *** (see attached image). Thanks, RS From: oldmanl...@gmail.com Date: Thu, 19 Aug 2010 17:33:03 +0200 To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Can't file in *.st exports Pardon me for being blunt, Robert, but we're going to need a bit more to go on than some sort of weird system error. Could you please attach a file that you tried to file in, and maybe a screenshot of the error? It would certainly increase your chances of getting some help ;-) -- Cheers, Peter. On 19 aug 2010, at 17:11, Robert Sirois watchl...@hotmail.com wrote: There's some sort of weird system error when I try to fileIn a *.st file (like a class method). It asks me to CR for a debugger or any key to restart. I ended up having to force quit. This is in the latest 1.1 one-click. Thanks, RS ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Fwd: [Esug-list] Looking for Smalltalkers
Begin forwarded message: From: Georg Heeg ge...@heeg.de Date: August 19, 2010 12:33:15 PM GMT+02:00 To: ESUG Members esug-l...@lists.esug.org Subject: [Esug-list] Looking for Smalltalkers Reply-To: esug-l...@lists.esug.org Dear Smalltalkers, We are looking to enlarge our Smalltalk team in Köthen (Anhalt) or Dortmund. Georg Heeg Georg Heeg eK, Dortmund und Köthen, HR Dortmund A 12812 Tel. +49-3496-214328, Fax +49-3496-214712 ___ Esug-list mailing list esug-l...@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Wiki spam experience
Schwab,Wilhelm K wrote: Any wiki. If you want something more specific, does our Pharo site wiki remain unscarred because we control who can edit it, or is there something to stop me from doing bad things to it if I were so inclined? I am asking on behalf of somone who has had problems with a wider audience. You could refer to James Robertson's blog posts on how he handles comments for his blog (I recall he has lots of different strategies that he's incorporated) Tim ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] moose images for cog vm
Hi, Given the nice recent improvements of the Cog VM, the hudson.moosetechnology.org continuous integration server now produces Moose images that work with this VM: http://hudson.moosetechnology.org/job/moose-latest-dev-for-cog/ Cheers, Doru -- www.tudorgirba.com If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] organization
so far we have SystemDictionaryorganization Return the organizer for the receiver ^SystemOrganization so it means that this is global in Smalltalk globals. But I'm skeptical that this can work for another instance of SystemDictionary and even if this works I find this code brittle since it relies on the compiler global look up. I was thinking that either defining an organization as an instance variable SystemDictionary would make sense or using an explicit lookup in the instance itself. SystemDictionaryorganization Return the organizer for the receiver ^ self at: #SystemOrganization now I'm dead so I need other eyes. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [Moose-dev] moose images for cog vm
could you still have the old one in addition? I think that this is good to have a slow system to find that we are missing basic optimization. On Aug 19, 2010, at 10:27 PM, Tudor Girba wrote: Hi, Given the nice recent improvements of the Cog VM, the hudson.moosetechnology.org continuous integration server now produces Moose images that work with this VM: http://hudson.moosetechnology.org/job/moose-latest-dev-for-cog/ Cheers, Doru -- www.tudorgirba.com If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut. ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [Moose-dev] Re: moose images for cog vm
There are several images built on this server: http://hudson.moosetechnology.org/ The base one works with the standard Pharo 1.1: http://hudson.moosetechnology.org/job/moose-latest-dev/ Cheers, Doru On 19 Aug 2010, at 22:35, Stéphane Ducasse wrote: could you still have the old one in addition? I think that this is good to have a slow system to find that we are missing basic optimization. On Aug 19, 2010, at 10:27 PM, Tudor Girba wrote: Hi, Given the nice recent improvements of the Cog VM, the hudson.moosetechnology.org continuous integration server now produces Moose images that work with this VM: http://hudson.moosetechnology.org/job/moose-latest-dev-for-cog/ Cheers, Doru -- www.tudorgirba.com If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut. ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com Some battles are better lost than fought. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] organization
Stef, As part of his GSoC 2010 project, Germán Leiva has been doing some refactoring of this and has some sample code at http://www.squeaksource.com/Environments.html. While it hasn't come as far as I hoped, it does give an interesting insight into some of the relationships between environment, organization, and related things (the Monticello implications were somewhat nontrivial). Although the GSoC is officially over, I expect to be working on this going forward and would like to have a significant discussion with interested parties at ESUG next month. How quickly do you want to solve this? ;-) James On Aug 19, 2010, at 1:29 PM, stephane ducasse wrote: so far we have SystemDictionaryorganization Return the organizer for the receiver ^SystemOrganization so it means that this is global in Smalltalk globals. But I'm skeptical that this can work for another instance of SystemDictionary and even if this works I find this code brittle since it relies on the compiler global look up. I was thinking that either defining an organization as an instance variable SystemDictionary would make sense or using an explicit lookup in the instance itself. SystemDictionaryorganization Return the organizer for the receiver ^ self at: #SystemOrganization now I'm dead so I need other eyes. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] cogVM in pharo {WAS} Re: [squeak-dev] Re: HTML parser (again)
On Wed, Aug 18, 2010 at 11:05 PM, stephane ducasse stephane.duca...@gmail.com wrote: no CogVM is not ready for us. why not? It tohught it was everything working but objects as methods is there something else? Is there a one-click image for CogVM somewhere so I can download it? On Wed, Aug 18, 2010 at 2:34 AM, laurent laffont laurent.laff...@gmail.com wrote: On Wed, Aug 18, 2010 at 7:50 AM, Andrei Stebakov lisper...@gmail.com wrote: I've been looking for a nice and fast HTML parser. I've found Zulq Alam's Soup (http://www.squeaksource.com/@vHckXt8_6gVtXFxy/XMrjDbIs) it looks nice but it's way too slow for me (takes 5 sec to parse the page, my current lisp parser takes about 1 sec for that.) I found another one, Todd Blanchard's HTML and CSS parser (http://www.squeaksource.com/@iMgHmTKVxU00wEdz/A0jkqk71) but I couldn't load it into Pharo 1.1 or Squeak 4.1. It complains about some syntax error and leaves the progress bar which I can't kill... I wonder if anyone (Todd?) can take a look at the parser and figure out how to fix it? What other options I have for an HTML parser? Looking at Pharo speed I wonder if there is any way to optimize it? Is JIT or some other speed optimization in plans for Pharo/Squeak? What do you need to do ? There's XMLSupport http://www.squeaksource.com/XMLSupport.html Scamper might have a standalone HTML parser http://www.squeaksource.com/Scamper.html The CogVM has JIT. Laurent. Thank you, Andrei ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Can't file in *.st exports
No, PharoSound on squeaksource, I also merged some fixes from squeak trunk a few weeks ago. Den 19. aug. 2010 kl. 22:13 skrev Stéphane Ducasse stephane.duca...@inria.fr: Thanks henrik, you uploaded the code in the pharoNonCore repo? Stef On Aug 19, 2010, at 8:20 PM, Henrik Johansen wrote: There are three senders of #clone in the 1.1 One-click image, all part of the sound package. (I've uploaded a new version to PharoSound where this is fixed, and #copy occurences replaced with #postCopy implementations instead). ArrayedCollectionmergeSortFrom:to:by uses shallowCopy. I'd check what code you've imported which has changed that. Cheers, Henry On Aug 19, 2010, at 6:49 43PM, Peter Hugosson-Miller wrote: Better :-) The attached image is of a stack trace that shows where the error occurs, which is certainly helpful! During the execution of ArrayedCollection#mergeSortFrom:to:by:, the message #clone is sent to an instance of Array, and the message is not understood, which means that there is no method called #clone in the Array class or any of its superclasses. So the question is, why is the message being sent, when no corresponding method exists on the receiver? One possibility is that there is an error in the method where the #clone message is being sent, or that the missing method just hasn't been filed in yet. The next step would probably be to look at the file being filed in, and see what methods it contains. Perhaps it depends on another file that needs to be filed in first? -- Cheers, Peter 2010/8/19 Robert Sirois watchl...@hotmail.com No problem, Pharo's driving me crazy today hehe. It says: *** system error handling failed *** (see attached image). Thanks, RS From: oldmanl...@gmail.com Date: Thu, 19 Aug 2010 17:33:03 +0200 To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Can't file in *.st exports Pardon me for being blunt, Robert, but we're going to need a bit more to go on than some sort of weird system error. Could you please attach a file that you tried to file in, and maybe a screenshot of the error? It would certainly increase your chances of getting some help ;-) -- Cheers, Peter. On 19 aug 2010, at 17:11, Robert Sirois watchl...@hotmail.com wrote: There's some sort of weird system error when I try to fileIn a *.st file (like a class method). It asks me to CR for a debugger or any key to restart. I ended up having to force quit. This is in the latest 1.1 one-click. Thanks, RS ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.2] #12100
12100 - - Enter back to accept TextEntryDialogWindow. Thanks Gary Chambers. - Issue 2833: Pharo 1.1 final has two senders of #haltOnce - fixes some Smalltalk - Smalltalk globals ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Probably a bug
On 08/19/2010 09:53 PM, Stéphane Ducasse wrote: What would you say the right thing is? Well, intuitively I would say that converting an Array of Character instances (say 5 instances) using asString would give me a String of size 5. Also, Character space asString does NOT give me 'Character space' but actually ' '. Maybe its just me, but I'd rather not have SequenceableCollection asString mean If I contain only elements which may represent characters, return a string containing those, if not, return my printString yes you are not the only one. Thanks I was thinking about that after my post :) Having a fallback on printString is of course fine, in Object. But... well, I haven't thought *deeply* on this, but a sequencable collection of Characters should IMHO be able to produce a String regards, Göran And it is, using either collection as: String, or String withAll: collection In both cases you then explicitly specify that this collection will contain only elements which can be converted to a string, rather than have a later reader of the code have to question hmmm, does the use of asString here mean he'll be using the collections printString, or the string with its elements? I'm curious about the senders of asString, especially to collection. Stef I am all in agreement I think, my gut reaction was that, darn, something is broken. But perhaps sending asString to a Collection of objects should... well, what *should* it return? I think possibly one of the problems in all this is the fallback on printString - that has clearly muddled the waters IMHO. #printString is for the tools, it should give a readable representation. But #asString is a conversion method - it should give me IMHO the most reasonable conversion for further use. I agree that #as: etc might be a better protocol, but let's say we still want #asString to work for Collections and NOT fall back on #printString - then what should it do? regards, Göran ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] About changes logging
Hi I noticed that if I define a method it shows up in the recentMessageSet Now if I load code with mc it does not, even though it is logged in the changes (the logging in the changes is done by SmalltalkImageevent:) which could indicate that SystemChangeNotifier notified the right tools. Does anybody have an idea? Because this is confusing. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] organization
Stef, As part of his GSoC 2010 project, Germán Leiva has been doing some refactoring of this and has some sample code at http://www.squeaksource.com/Environments.html. While it hasn't come as far as I hoped, it does give an interesting insight into some of the relationships between environment, organization, and related things (the Monticello implications were somewhat nontrivial). Although the GSoC is officially over, I expect to be working on this going forward and would like to have a significant discussion with interested parties at ESUG next month. How quickly do you want to solve this? ;-) Ok we will discuss. Stef James On Aug 19, 2010, at 1:29 PM, stephane ducasse wrote: so far we have SystemDictionaryorganization Return the organizer for the receiver ^SystemOrganization so it means that this is global in Smalltalk globals. But I'm skeptical that this can work for another instance of SystemDictionary and even if this works I find this code brittle since it relies on the compiler global look up. I was thinking that either defining an organization as an instance variable SystemDictionary would make sense or using an explicit lookup in the instance itself. SystemDictionaryorganization Return the organizer for the receiver ^ self at: #SystemOrganization now I'm dead so I need other eyes. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] organization
IIRC Germán told me that the extensions of the package in the repository should be refactors to make in Pharo, and there are things there related to enviroments and system organization. On Thu, Aug 19, 2010 at 5:49 PM, James Foster smallt...@jgfoster.netwrote: Stef, As part of his GSoC 2010 project, Germán Leiva has been doing some refactoring of this and has some sample code at http://www.squeaksource.com/Environments.html. While it hasn't come as far as I hoped, it does give an interesting insight into some of the relationships between environment, organization, and related things (the Monticello implications were somewhat nontrivial). Although the GSoC is officially over, I expect to be working on this going forward and would like to have a significant discussion with interested parties at ESUG next month. How quickly do you want to solve this? ;-) James On Aug 19, 2010, at 1:29 PM, stephane ducasse wrote: so far we have SystemDictionaryorganization Return the organizer for the receiver ^SystemOrganization so it means that this is global in Smalltalk globals. But I'm skeptical that this can work for another instance of SystemDictionary and even if this works I find this code brittle since it relies on the compiler global look up. I was thinking that either defining an organization as an instance variable SystemDictionary would make sense or using an explicit lookup in the instance itself. SystemDictionaryorganization Return the organizer for the receiver ^ self at: #SystemOrganization now I'm dead so I need other eyes. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Probably a bug
2010/8/19 Göran Krampe go...@krampe.se On 08/19/2010 09:53 PM, Stéphane Ducasse wrote: What would you say the right thing is? Well, intuitively I would say that converting an Array of Character instances (say 5 instances) using asString would give me a String of size 5. Also, Character space asString does NOT give me 'Character space' but actually ' '. Maybe its just me, but I'd rather not have SequenceableCollection asString mean If I contain only elements which may represent characters, return a string containing those, if not, return my printString yes you are not the only one. Thanks I was thinking about that after my post :) Having a fallback on printString is of course fine, in Object. But... well, I haven't thought *deeply* on this, but a sequencable collection of Characters should IMHO be able to produce a String regards, Göran And it is, using either collection as: String, or String withAll: collection In both cases you then explicitly specify that this collection will contain only elements which can be converted to a string, rather than have a later reader of the code have to question hmmm, does the use of asString here mean he'll be using the collections printString, or the string with its elements? I'm curious about the senders of asString, especially to collection. Stef I am all in agreement I think, my gut reaction was that, darn, something is broken. But perhaps sending asString to a Collection of objects should... well, what *should* it return? I think possibly one of the problems in all this is the fallback on printString - that has clearly muddled the waters IMHO. #printString is for the tools, it should give a readable representation. But #asString is a conversion method - it should give me IMHO the most reasonable conversion for further use. I agree that #as: etc might be a better protocol, but let's say we still want #asString to work for Collections and NOT fall back on #printString - then what should it do? If aCollection asArray = (aCollection as: Array) then surely aCollection asString = (aCollection as: String) If ([aCollection as: String. nil] on: Error do: [:ex| ex]) notNil then surely ([aCollection as: String. nil] on: Error do: [:ex| ex messageText]) = ([aCollection asString. nil] on: Error do: [:ex| ex messageText]) i.e. if aCollection doesn't include characters both forms should return errors. I find the Object implementation of asString distasteful, but that's juts my taste. However, I find Collection's inheriting of that definition badly broken. my 2¢ best Eliot regards, Göran ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] cogVM in pharo {WAS} Re: [squeak-dev] Re: HTML parser (again)
I do not know. Plugin? Then there are compiler changes (may be this is for the closure). Stef On Aug 19, 2010, at 10:49 PM, Mariano Martinez Peck wrote: On Wed, Aug 18, 2010 at 11:05 PM, stephane ducasse stephane.duca...@gmail.com wrote: no CogVM is not ready for us. why not? It tohught it was everything working but objects as methods is there something else? Is there a one-click image for CogVM somewhere so I can download it? On Wed, Aug 18, 2010 at 2:34 AM, laurent laffont laurent.laff...@gmail.com wrote: On Wed, Aug 18, 2010 at 7:50 AM, Andrei Stebakov lisper...@gmail.com wrote: I've been looking for a nice and fast HTML parser. I've found Zulq Alam's Soup (http://www.squeaksource.com/@vHckXt8_6gVtXFxy/XMrjDbIs) it looks nice but it's way too slow for me (takes 5 sec to parse the page, my current lisp parser takes about 1 sec for that.) I found another one, Todd Blanchard's HTML and CSS parser (http://www.squeaksource.com/@iMgHmTKVxU00wEdz/A0jkqk71) but I couldn't load it into Pharo 1.1 or Squeak 4.1. It complains about some syntax error and leaves the progress bar which I can't kill... I wonder if anyone (Todd?) can take a look at the parser and figure out how to fix it? What other options I have for an HTML parser? Looking at Pharo speed I wonder if there is any way to optimize it? Is JIT or some other speed optimization in plans for Pharo/Squeak? What do you need to do ? There's XMLSupport http://www.squeaksource.com/XMLSupport.html Scamper might have a standalone HTML parser http://www.squeaksource.com/Scamper.html The CogVM has JIT. Laurent. Thank you, Andrei ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Probably a bug
I checked a bit the senders of asString and the problem is that they often confused printString and asString. Like kent beck I do not like conversion methods between object that do not have the same API ie aBag asSet is ok but aString asUrl is not good for me. I understand aText asString but not really aColor asString, I would prefer a Color printString especially since asString seems inherited from Object and calling printString. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Probably a bug
+1 On 19 Aug 2010, at 18:03, Stéphane Ducasse wrote: I checked a bit the senders of asString and the problem is that they often confused printString and asString. Like kent beck I do not like conversion methods between object that do not have the same API ie aBag asSet is ok but aString asUrl is not good for me. I understand aText asString but not really aColor asString, I would prefer a Color printString especially since asString seems inherited from Object and calling printString. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Can't file in *.st exports
Could the same also be true of Number, Dictionary, and OrderedCollection? I'll have to double check at home, but I was also trying to import additions to those classes as well. Thanks for the info, RS From: henrik.s.johan...@veloxit.no Date: Thu, 19 Aug 2010 22:51:19 +0200 To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Can't file in *.st exports No, PharoSound on squeaksource, I also merged some fixes from squeak trunk a few weeks ago. Den 19. aug. 2010 kl. 22:13 skrev Stéphane Ducasse stephane.duca...@inria.fr: Thanks henrik, you uploaded the code in the pharoNonCore repo? Stef On Aug 19, 2010, at 8:20 PM, Henrik Johansen wrote: There are three senders of #clone in the 1.1 One-click image, all part of the sound package. (I've uploaded a new version to PharoSound where this is fixed, and #copy occurences replaced with #postCopy implementations instead). ArrayedCollectionmergeSortFrom:to:by uses shallowCopy. I'd check what code you've imported which has changed that. Cheers, Henry On Aug 19, 2010, at 6:49 43PM, Peter Hugosson-Miller wrote: Better :-) The attached image is of a stack trace that shows where the error occurs, which is certainly helpful! During the execution of ArrayedCollection#mergeSortFrom:to:by:, the message #clone is sent to an instance of Array, and the message is not understood, which means that there is no method called #clone in the Array class or any of its superclasses. So the question is, why is the message being sent, when no corresponding method exists on the receiver? One possibility is that there is an error in the method where the #clone message is being sent, or that the missing method just hasn't been filed in yet. The next step would probably be to look at the file being filed in, and see what methods it contains. Perhaps it depends on another file that needs to be filed in first? -- Cheers, Peter 2010/8/19 Robert Sirois watchl...@hotmail.com No problem, Pharo's driving me crazy today hehe. It says: *** system error handling failed *** (see attached image). Thanks, RS From: oldmanl...@gmail.com Date: Thu, 19 Aug 2010 17:33:03 +0200 To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Can't file in *.st exports Pardon me for being blunt, Robert, but we're going to need a bit more to go on than some sort of weird system error. Could you please attach a file that you tried to file in, and maybe a screenshot of the error? It would certainly increase your chances of getting some help ;-) -- Cheers, Peter. On 19 aug 2010, at 17:11, Robert Sirois watchl...@hotmail.com wrote: There's some sort of weird system error when I try to fileIn a *.st file (like a class method). It asks me to CR for a debugger or any key to restart. I ended up having to force quit. This is in the latest 1.1 one-click. Thanks, RS ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] code licenses...was HTML parser (again))
Stéphane Ducasse wrote: Yes with first class package we could attach the license to the package Now with the work of Carla I would like to resurrect the DrDoc Project so that we get a kind of manifesto = a special class per package that contains the doc and the license. A...sounds cool ... Stef Stéphane Ducasse wrote: Yes we should do something. Now the question is how to do something that we can actually implement. I think that we should - start to identify package of interest (quality/topics) - check their license status - check the author and get access - create an inbox Stef Stef, speaking of licenses...I was thinking that for mcz files, we should have a directory of each mcz file that contains the license statement for the code in that _version_ of the mcz file. Most tools would end up ignoring, but if we started including the license _in_ the mcz file, then license status would be _much clearer_. I also assume that a similar addition to mc2 files could/should be done Dale ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Wrap .a into a .so for use by FFI
Hello all, In short, I have a static library (.a) and want to make a shared library (.so) that exports all of the functions in the static library for use by FFI. I have something building, but it is presumably being too helpful and stripping out the unreferenced symbols, leaving me with nothing?? Is there an easy way to include the code in the resulting .so? I am starting to work with a data acquisition board from Access IO. My original plan was to write something in C++ that would wrap the board and driver with a socket server. The idea was to get the benefit of a separate OS process that could aggressively (quasi real time) move data as needed, allowing Pharo to simply read from a socket and otherwise be unblocked. On re-reading some of the documentation, this could turn out to be as simple as calling a few functions to set options, allocating a block of memory and calling a funtion to turn the board loose to fill the buffer with data. In this model, I would then, on timer or user interaction, call a polling function to see how much of the buffer has yet to be filled. It might turn out to be very simple to do. Snag: there is no .so, so AFAICT, there is nothing to ask FFI to load; I am mostly concerned with doing this on Linux. I created a quick .so project and linked the (.a) static library. The result builds, but at 5.3 kb, it cannot possibly contain the code I hope to put in it. I am looking at options such as -export-dynamic and hunting around for ways to disable stripping or similar concepts. Any ideas? Worst case, I could add functions that wrap the functions I want to call and bind FFI to them, but that is hopefully not necesssary. The closest I have come to this is the Gnu Scientific Library. The Linux .so files would not load due to cyclic dependencies between BLAS and the balance of the library, and it was clear from searches that they had no plans to fix it (oh, that's one of those dynamic languages). I was easily able to create a shared library that links both parts of GSL, exports a few functions to avoid having to roll my own callbacks, and all is well. Either I got lucky with the exports and any relevant options, or the .so's make the problem less challenging than my current task. Bill ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Wrap .a into a .so for use by FFI
Hello all, With no small amount of help, I might have done it!!! :) After a few overly verbose sets of search results, something like convert .a to .so turned up the following: http://www.linuxquestions.org/questions/linux-software-2/convert-static-library-filename-a-to-dynamic-shared-object-filename-so-465709/ In this case, the natural steps are: ar -x libaiousb.a gcc -shared *.o -o libAccessIO-USB.so rm *.o Hitting the resulting .so with objdump suggests that it might be what I need. It will take some time to create and check the bindings, but I'm optimistic. At the least, it was a nice exercise. More to come. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K [bsch...@anest.ufl.edu] Sent: Thursday, August 19, 2010 9:31 PM To: Pharo-project@lists.gforge.inria.fr; squeak-...@lists.squeakfoundation.org Subject: [Pharo-project] Wrap .a into a .so for use by FFI Hello all, In short, I have a static library (.a) and want to make a shared library (.so) that exports all of the functions in the static library for use by FFI. I have something building, but it is presumably being too helpful and stripping out the unreferenced symbols, leaving me with nothing?? Is there an easy way to include the code in the resulting .so? I am starting to work with a data acquisition board from Access IO. My original plan was to write something in C++ that would wrap the board and driver with a socket server. The idea was to get the benefit of a separate OS process that could aggressively (quasi real time) move data as needed, allowing Pharo to simply read from a socket and otherwise be unblocked. On re-reading some of the documentation, this could turn out to be as simple as calling a few functions to set options, allocating a block of memory and calling a funtion to turn the board loose to fill the buffer with data. In this model, I would then, on timer or user interaction, call a polling function to see how much of the buffer has yet to be filled. It might turn out to be very simple to do. Snag: there is no .so, so AFAICT, there is nothing to ask FFI to load; I am mostly concerned with doing this on Linux. I created a quick .so project and linked the (.a) static library. The result builds, but at 5.3 kb, it cannot possibly contain the code I hope to put in it. I am looking at options such as -export-dynamic and hunting around for ways to disable stripping or similar concepts. Any ideas? Worst case, I could add functions that wrap the functions I want to call and bind FFI to them, but that is hopefully not necesssary. The closest I have come to this is the Gnu Scientific Library. The Linux .so files would not load due to cyclic dependencies between BLAS and the balance of the library, and it was clear from searches that they had no plans to fix it (oh, that's one of those dynamic languages). I was easily able to create a shared library that links both parts of GSL, exports a few functions to avoid having to roll my own callbacks, and all is well. Either I got lucky with the exports and any relevant options, or the .so's make the problem less challenging than my current task. Bill ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
