Re: [Pharo-project] FEATURE: User chooses preferred location for MC directory repositories
we should add that to the pharo book :)
On Apr 21, 2010, at 2:42 AM, Dale Henrichs wrote:
Sean,
Don't know if this has already mentioned, but you can programmatically add
Directory repositories as follows:
| repo |
{'/path/to/repositories/project-1/'. '/path/to/repositories/project-2/'.
'/path/to/repositories/project-3/'. } do: [:path |
repo := MCDirectoryRepository new directory:
(FileDirectory on: path).
MCRepositoryGroup default addRepository: repo ].
- Sean P. DeNigris s...@clipperadams.com wrote:
| I'll give you my use case:
| I share my projects among a few images, and I like to keep them in
| sub-
| directories like:
| /path/to/repositories/project-1/
| /path/to/repositories/project-2/
| /path/to/repositories/project-3/
| So each one of these is a separate, unrelated repository in a common
|
| parent directory for ease of finding.
|
| So when I +Repository to each image, I have to navigate from the
| default directory to my repository for each new repository. If I can
|
| pick a start directory once as a setting, I can add new project's sub-
|
| directory or open them without any navigation.
|
| Does that make sense?
|
| Sean
|
| On Apr 20, 2010, at 1:33 PM, Chris Muller-3 [via Smalltalk]
| ml-node+2017760-613088063-217...@n4.nabble.com
| wrote:
|
| Whether the user is required to specify a default directory or a
| directory to a repository, it's the same task isn't it?
|
| Once you add it once to MC, it can be added to any other package.
| So this defaultDirectory would seem to be a feature not worth its
| weight..
|
|
| On Mon, Apr 19, 2010 at 6:00 PM, Sean P. DeNigris [hidden email]
|
| wrote:
|
|
| http://code.google.com/p/pharo/issues/detail?id=2329
|
| Pharo image: Pharo 1.0
|
| In Monticello Browser, when I click +Repository and select
| directory,
| I'd love to be taken right to the directory where I keep my local
| repositories, instead of having to click to the same place over
| and over.
|
| I changed the following method:
| MCDirectoryRepository classmorphicConfigure
| ^ (UIManager default chooseDirectoryFrom: (FileDirectory
| on:
| '/path/to/my/Repositories')) ifNotNil:
| [:directory |
| self new directory: directory]
|
| How should I store the default repository directory? Would anyone
|
| else find
| this helpful?
|
| Sean DeNigris
| --
| View this message in context:
|
http://n4.nabble.com/FEATURE-User-chooses-preferred-location-for-MC-directory-repositories-tp2016684p2016684.html
| Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
|
| ___
| Pharo-project mailing list
| [hidden email]
|
| http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
|
|
| ___
| Pharo-project mailing list
| [hidden email]
| http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
|
| View message @
|
http://n4.nabble.com/FEATURE-User-chooses-preferred-location-for-MC-directory-repositories-tp2016684p2017760.html
| To unsubscribe from FEATURE: User chooses preferred location for MC
|
| directory repositories, click here.
|
|
| --
| View this message in context:
|
http://n4.nabble.com/FEATURE-User-chooses-preferred-location-for-MC-directory-repositories-tp2016684p2018216.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] what expectedfailures expected to do?
On Apr 20, 2010, at 11:20 PM, Adrian Lienhard wrote: Yes, if a test that is expected to fail does not fail, this is treated as a failure. I think that makes sense. well it depends about the scenario. you put on expectedfailures something that gets in your way now, so after if it works even better. of course you should get notified that the test is green while expected it to failed. Now it leads to a UI problem where you have a failure that passes so when you click on it nothing happens: no debugger. And you can wonder why the hell do I have a failure when my tests pass. So I think that this implementation of expectedFailures is a hack. Adrian On Apr 20, 2010, at 21:57 , Stéphane Ducasse wrote: Hi I tagged some tests as expected failures and I got a strange behavior. On the the tests which was passing was listed under the failures. When I renamed the method without updating the expected failures my bar was green. So expected failures really expect that the tests failed? We cannto have green tests in there? 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] FEATURE: User chooses preferred location for MC directory repositories
On Tue, Apr 20, 2010 at 11:21 PM, Michael Roberts m...@mjr104.co.uk wrote: i'm not sure what either of you mean. I want there to be no UI choice and the system just looks higher up in the file system hierarchy. certainly environment variables or a .pharorc style file would solve this. On my machine I've written these files: ~/.pharorc.st Author fullName: 'LaurentLaffont'. MCRepositoryGroup default addRepository: (MCDirectoryRepository new directory: (FileDirectory on: '/home/laurent/pharo/repository')). Then ~/bin/pharo: #!/bin/sh squeak $1 ~/.pharorc.st Then I launch my image with: pharo /path/to/my.image Author and repository always set for every image. Very emacs-like :) Cheers, Laurent Laffont thanks, Mike On Tue, Apr 20, 2010 at 6:33 PM, Chris Muller asquea...@gmail.com wrote: Whether the user is required to specify a default directory or a directory to a repository, it's the same task isn't it? Once you add it once to MC, it can be added to any other package. So this defaultDirectory would seem to be a feature not worth its weight.. On Mon, Apr 19, 2010 at 6:00 PM, Sean P. DeNigris s...@clipperadams.com wrote: http://code.google.com/p/pharo/issues/detail?id=2329 Pharo image: Pharo 1.0 In Monticello Browser, when I click +Repository and select directory, I'd love to be taken right to the directory where I keep my local repositories, instead of having to click to the same place over and over. I changed the following method: MCDirectoryRepository classmorphicConfigure ^ (UIManager default chooseDirectoryFrom: (FileDirectory on: '/path/to/my/Repositories')) ifNotNil: [:directory | self new directory: directory] How should I store the default repository directory? Would anyone else find this helpful? Sean DeNigris -- View this message in context: http://n4.nabble.com/FEATURE-User-chooses-preferred-location-for-MC-directory-repositories-tp2016684p2016684.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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Running Alien on Windows
Thanx Torsten. I used the VM provided by Marco and it woked well. I run a few Pharo kernel tests and got them green. Do you know any limitations of this old VM (based on 3.11.5) / incompatiblities with Pharo ? Or, are there some major improvement done since a month. The current windows VM is 4.0.2... Noury On 20 avr. 10, at 19:24, Torsten Bergmann wrote: Bouraqadi Noury wrote on pharo-dev We have trouble running alien on Windows. Starting from a clean pharo 1.0 image and the latest VM, Would not work out of the box with the VM since it requires VM changes. Marco ported them from Newspeak and made them available [1]. Tests went green and he is sucessfully using Alien on Windows. But it is not yet in the official Squeak VM (which is 4.0.2.). There is also an issue for pharo [2] and an issue for VM developers [3] to follow progress. So the code is there and is ready for integration. Andreas asked for the license [4], Marco answered that code was from Newspeak [5]. After that we got a good response from John McIntosh on the license issue [6] which should be OK now. (Dont know, I'm not a lawyer) After I asked Andreas again he answered that it is not highest priority for him which I understood since Squeak 4.1 was in preparation. See last response regarding this [7] Dont know what should be the next steps to get Alien into the Win32-VM code base. Maybe Andreas could tell you more. As a workaround you could use the source provided by Marco to build your own unofficial VM - however you would have to reintegrate anytime Andreas makes a new release... Bye T. [1] http://lists.squeakfoundation.org/pipermail/vm-dev/2010-March/003983.html [2] http://code.google.com/p/pharo/issues/detail?id=1360 [3] http://bugs.squeak.org/view.php?id=7475 [4] http://lists.squeakfoundation.org/pipermail/vm-dev/2010-March/004034.html [5] http://lists.squeakfoundation.org/pipermail/vm-dev/2010-March/004037.html [6] http://lists.squeakfoundation.org/pipermail/vm-dev/2010-March/004054.html [7] http://lists.squeakfoundation.org/pipermail/vm-dev/2010- March/004103.html -- 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
Re: [Pharo-project] FEATURE: User chooses preferred location for MC directory repositories
Cool I will do that too. Can you create a book entry with that because this is cool :) Stef On Apr 21, 2010, at 8:40 AM, laurent laffont wrote: On Tue, Apr 20, 2010 at 11:21 PM, Michael Roberts m...@mjr104.co.uk wrote: i'm not sure what either of you mean. I want there to be no UI choice and the system just looks higher up in the file system hierarchy. certainly environment variables or a .pharorc style file would solve this. On my machine I've written these files: ~/.pharorc.st Author fullName: 'LaurentLaffont'. MCRepositoryGroup default addRepository: (MCDirectoryRepository new directory: (FileDirectory on: '/home/laurent/pharo/repository')). Then ~/bin/pharo: #!/bin/sh squeak $1 ~/.pharorc.st Then I launch my image with: pharo /path/to/my.image Author and repository always set for every image. Very emacs-like :) Cheers, Laurent Laffont thanks, Mike On Tue, Apr 20, 2010 at 6:33 PM, Chris Muller asquea...@gmail.com wrote: Whether the user is required to specify a default directory or a directory to a repository, it's the same task isn't it? Once you add it once to MC, it can be added to any other package. So this defaultDirectory would seem to be a feature not worth its weight.. On Mon, Apr 19, 2010 at 6:00 PM, Sean P. DeNigris s...@clipperadams.com wrote: http://code.google.com/p/pharo/issues/detail?id=2329 Pharo image: Pharo 1.0 In Monticello Browser, when I click +Repository and select directory, I'd love to be taken right to the directory where I keep my local repositories, instead of having to click to the same place over and over. I changed the following method: MCDirectoryRepository classmorphicConfigure ^ (UIManager default chooseDirectoryFrom: (FileDirectory on: '/path/to/my/Repositories')) ifNotNil: [:directory | self new directory: directory] How should I store the default repository directory? Would anyone else find this helpful? Sean DeNigris -- View this message in context: http://n4.nabble.com/FEATURE-User-chooses-preferred-location-for-MC-directory-repositories-tp2016684p2016684.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 ___ 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] FFI in 1.1
On Apr 21, 2010, at 12:09 AM, Eliot Miranda wrote: Hi All, 2010/4/20 John M McIntosh john...@smalltalkconsulting.com Well I asked for it... (a) you can get graphic cut/copy/paste of complex data on the macintosh and windows. (b) I'd rather have people learn FFI Alien so they can build their own api to Rome, Pango, Curl instead of waiting on about 4 people in the world to get around to building and distributing *official* plugins . I agree with this, but I also understand the security and modularity concerns of those who want to deploy without FFI and with plugins only. I think it might be worth-while, and would certainly be feasible and fun, to write an automatic plugin generator, e.g. above David's SmartSyntaxPlugin, that would take a set of FFI methods and shrink-wrap them into a plugin. So the natural development cycle for plugins could become prototype and extend using the FFI and deploy via the generator and a plugin compilation step. That would be analogous to the approach taken to produce the VM itself. Thanks this is good to get a vision in that area. We go in that direction now this is more a problem of knwoledge than will so we will work on making the VM knowledge more spread in the community. I hope this approach would make it easier for people to produce plugins, since more of the gubbins would be hidden. That might be naive given complications with mapping object and memory references across the boundary, but it might also be an easier way to integrate things like Andreas' proposed handle framework. Sounds good. I do not get anything but trying to learn. :) (c) When your curl, rome, etc FFI call freaks and toasts your image why you can do debugging, versus relying on a handful of people in the world to grind thru some compiler, gnu debug session to figure out why that register move results in a fatal Virtual memory page fault. Certainly we got some good mileage out of catching external errors in FFI calls and returning these as primitive error codes. Basically it helps you find which FFI calls cause crashes, because the system will typically stay up long enough for you to open the debugger and identify which FFI call failed and what its arguments were. Why the call failed isn't so easy. The errr codes are an address and some OS-specific exception identifier. One then either has to think hard (infer from the args why the call might fail) or decamp to a low-level debugger, rerun the call and use any additional info it provides to debug the call. This is easy to add to the current VM which already has fatal signal handlers and primitive error codes. The FFI must set a flag in FFI call (clearing on callback, resetting on return from callback) which is tested in the fatal signal handlers and cause the exception info to be squirrelled away and the FFI call to fail. If the VM has enough state to take a callback it typically has enough state to cause the current FFI callout to fail and from the fatal signal handler longjmp to somewhere that can continue execution through the primitive failure. (and if it doesn't now, it can be made to, and not on every FFI call either, e.g. the interpreter can call setjmp prior to entering the interpreter loop, Cog does this to be able to switch between native code and interpreted code) well when will we get more Cog improvements in the vm? 2¢ Eliot On 2010-04-19, at 11:41 PM, Torsten Bergmann wrote: I wouldn't include neither FFI or Alien FFI in neither PharoCore or PharoDev image. +1 That's only my opinion. Maybe Stef should tell us more about why he thinks it should be included. Bye 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 -- === 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 ___ 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] FFI in 1.1
On Apr 21, 2010, at 9:06 AM, Stéphane Ducasse wrote: On Apr 21, 2010, at 12:09 AM, Eliot Miranda wrote: Hi All, 2010/4/20 John M McIntosh john...@smalltalkconsulting.com Well I asked for it... (a) you can get graphic cut/copy/paste of complex data on the macintosh and windows. (b) I'd rather have people learn FFI Alien so they can build their own api to Rome, Pango, Curl instead of waiting on about 4 people in the world to get around to building and distributing *official* plugins . I agree with this, but I also understand the security and modularity concerns of those who want to deploy without FFI and with plugins only. I think it might be worth-while, and would certainly be feasible and fun, to write an automatic plugin generator, e.g. above David's SmartSyntaxPlugin, that would take a set of FFI methods and shrink-wrap them into a plugin. So the natural development cycle for plugins could become prototype and extend using the FFI and deploy via the generator and a plugin compilation step. That would be analogous to the approach taken to produce the VM itself. Thanks this is good to get a vision in that area. We go in that direction now this is more a problem of knwoledge than will so we will work on making the VM knowledge more spread in the community. I hope this approach would make it easier for people to produce plugins, since more of the gubbins would be hidden. That might be naive given complications with mapping object and memory references across the boundary, but it might also be an easier way to integrate things like Andreas' proposed handle framework. Sounds good. I do not get anything but trying to learn. :) anything/everything hopefully :) (c) When your curl, rome, etc FFI call freaks and toasts your image why you can do debugging, versus relying on a handful of people in the world to grind thru some compiler, gnu debug session to figure out why that register move results in a fatal Virtual memory page fault. Certainly we got some good mileage out of catching external errors in FFI calls and returning these as primitive error codes. Basically it helps you find which FFI calls cause crashes, because the system will typically stay up long enough for you to open the debugger and identify which FFI call failed and what its arguments were. Why the call failed isn't so easy. The errr codes are an address and some OS-specific exception identifier. One then either has to think hard (infer from the args why the call might fail) or decamp to a low-level debugger, rerun the call and use any additional info it provides to debug the call. This is easy to add to the current VM which already has fatal signal handlers and primitive error codes. The FFI must set a flag in FFI call (clearing on callback, resetting on return from callback) which is tested in the fatal signal handlers and cause the exception info to be squirrelled away and the FFI call to fail. If the VM has enough state to take a callback it typically has enough state to cause the current FFI callout to fail and from the fatal signal handler longjmp to somewhere that can continue execution through the primitive failure. (and if it doesn't now, it can be made to, and not on every FFI call either, e.g. the interpreter can call setjmp prior to entering the interpreter loop, Cog does this to be able to switch between native code and interpreted code) well when will we get more Cog improvements in the vm? 2¢ Eliot On 2010-04-19, at 11:41 PM, Torsten Bergmann wrote: I wouldn't include neither FFI or Alien FFI in neither PharoCore or PharoDev image. +1 That's only my opinion. Maybe Stef should tell us more about why he thinks it should be included. Bye 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 -- === 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 ___ 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
Re: [Pharo-project] FEATURE: User chooses preferred location for MC directory repositories
That's cool but we should look to resolve the rc file or env variables in the image then it doesn't rely on correctly configuring the command line invocation. shouldn't be too hard. I appreciate I hijacked this thread somewhat Cheers mike On Wednesday, April 21, 2010, Stéphane Ducasse stephane.duca...@inria.fr wrote: Cool I will do that too. Can you create a book entry with that because this is cool :) Stef On Apr 21, 2010, at 8:40 AM, laurent laffont wrote: On Tue, Apr 20, 2010 at 11:21 PM, Michael Roberts m...@mjr104.co.uk wrote: i'm not sure what either of you mean. I want there to be no UI choice and the system just looks higher up in the file system hierarchy. certainly environment variables or a .pharorc style file would solve this. On my machine I've written these files: ~/.pharorc.st Author fullName: 'LaurentLaffont'. MCRepositoryGroup default addRepository: (MCDirectoryRepository new directory: (FileDirectory on: '/home/laurent/pharo/repository')). Then ~/bin/pharo: #!/bin/sh squeak $1 ~/.pharorc.st Then I launch my image with: pharo /path/to/my.image Author and repository always set for every image. Very emacs-like :) Cheers, Laurent Laffont thanks, Mike On Tue, Apr 20, 2010 at 6:33 PM, Chris Muller asquea...@gmail.com wrote: Whether the user is required to specify a default directory or a directory to a repository, it's the same task isn't it? Once you add it once to MC, it can be added to any other package. So this defaultDirectory would seem to be a feature not worth its weight.. On Mon, Apr 19, 2010 at 6:00 PM, Sean P. DeNigris s...@clipperadams.com wrote: http://code.google.com/p/pharo/issues/detail?id=2329 Pharo image: Pharo 1.0 In Monticello Browser, when I click +Repository and select directory, I'd love to be taken right to the directory where I keep my local repositories, instead of having to click to the same place over and over. I changed the following method: MCDirectoryRepository classmorphicConfigure ^ (UIManager default chooseDirectoryFrom: (FileDirectory on: '/path/to/my/Repositories')) ifNotNil: [:directory | self new directory: directory] How should I store the default repository directory? Would anyone else find this helpful? Sean DeNigris -- View this message in context: http://n4.nabble.com/FEATURE-User-chooses-preferred-location-for-MC-directory-repositories-tp2016684p2016684.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] what expectedfailures expected to do?
Yea, I agree, the GUI is suboptimal. I still think, though, that treating this case as a failure is correct. For instance, consider the case where you had added a workaround to a known bug and when the bug is fixed you need to remove the workaround again. Maybe it even leads to a wrong behavior now that the bug is gone. In this case you really want to know that the test does not fail anymore. In any case, I think that tagging methods as expected failures should be done with pragmas and not with #expectedFailures. Like this it would also be much easier to understand what's going on when you have a failure in this test although all assertions pass. Adrian On Apr 21, 2010, at 08:22 , Stéphane Ducasse wrote: On Apr 20, 2010, at 11:20 PM, Adrian Lienhard wrote: Yes, if a test that is expected to fail does not fail, this is treated as a failure. I think that makes sense. well it depends about the scenario. you put on expectedfailures something that gets in your way now, so after if it works even better. of course you should get notified that the test is green while expected it to failed. Now it leads to a UI problem where you have a failure that passes so when you click on it nothing happens: no debugger. And you can wonder why the hell do I have a failure when my tests pass. So I think that this implementation of expectedFailures is a hack. Adrian On Apr 20, 2010, at 21:57 , Stéphane Ducasse wrote: Hi I tagged some tests as expected failures and I got a strange behavior. On the the tests which was passing was listed under the failures. When I renamed the method without updating the expected failures my bar was green. So expected failures really expect that the tests failed? We cannto have green tests in there? 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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Next smalltalk meetup cologne in june
Please join us on the 10th of June for the next Cologne Smalltalk User Meetup. Anyone interested in Smalltalk is invited, regardless if you only recently discovered the magic of doing things the Smalltalk way, are a die hard VM-Hacker, want to share your experience on web-development in Seaside or like to chit-chat while enjoying a Kölsch. We’re gonna meet at 7pm at Vision Factory GmbH Sömmeringstr. 75 50823 Köln (across the yard at the rear house) If you would like to do a presentation just let us know. Further information you'll find on http://colstme.selfish.org/ regards, Norbert ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] what expectedfailures expected to do?
On Apr 21, 2010, at 9:51 AM, Adrian Lienhard wrote: Yea, I agree, the GUI is suboptimal. I still think, though, that treating this case as a failure is correct. For instance, consider the case where you had added a workaround to a known bug and when the bug is fixed you need to remove the workaround again. Maybe it even leads to a wrong behavior now that the bug is gone. In this case you really want to know that the test does not fail anymore. yes Now I have the impression that expectedFailures should be like passes, failed, errors: a state of the tests. Stef In any case, I think that tagging methods as expected failures should be done with pragmas and not with #expectedFailures. Like this it would also be much easier to understand what's going on when you have a failure in this test although all assertions pass. Adrian On Apr 21, 2010, at 08:22 , Stéphane Ducasse wrote: On Apr 20, 2010, at 11:20 PM, Adrian Lienhard wrote: Yes, if a test that is expected to fail does not fail, this is treated as a failure. I think that makes sense. well it depends about the scenario. you put on expectedfailures something that gets in your way now, so after if it works even better. of course you should get notified that the test is green while expected it to failed. Now it leads to a UI problem where you have a failure that passes so when you click on it nothing happens: no debugger. And you can wonder why the hell do I have a failure when my tests pass. So I think that this implementation of expectedFailures is a hack. Adrian On Apr 20, 2010, at 21:57 , Stéphane Ducasse wrote: Hi I tagged some tests as expected failures and I got a strange behavior. On the the tests which was passing was listed under the failures. When I renamed the method without updating the expected failures my bar was green. So expected failures really expect that the tests failed? We cannto have green tests in there? 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 ___ 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] what expectedfailures expected to do?
I think Adrian Kuhn did that in his SUnit work. I also remember he also introduced a difference between expectedFailures and expectedErrors. Doru On 21 Apr 2010, at 10:16, Stéphane Ducasse wrote: On Apr 21, 2010, at 9:51 AM, Adrian Lienhard wrote: Yea, I agree, the GUI is suboptimal. I still think, though, that treating this case as a failure is correct. For instance, consider the case where you had added a workaround to a known bug and when the bug is fixed you need to remove the workaround again. Maybe it even leads to a wrong behavior now that the bug is gone. In this case you really want to know that the test does not fail anymore. yes Now I have the impression that expectedFailures should be like passes, failed, errors: a state of the tests. Stef In any case, I think that tagging methods as expected failures should be done with pragmas and not with #expectedFailures. Like this it would also be much easier to understand what's going on when you have a failure in this test although all assertions pass. Adrian On Apr 21, 2010, at 08:22 , Stéphane Ducasse wrote: On Apr 20, 2010, at 11:20 PM, Adrian Lienhard wrote: Yes, if a test that is expected to fail does not fail, this is treated as a failure. I think that makes sense. well it depends about the scenario. you put on expectedfailures something that gets in your way now, so after if it works even better. of course you should get notified that the test is green while expected it to failed. Now it leads to a UI problem where you have a failure that passes so when you click on it nothing happens: no debugger. And you can wonder why the hell do I have a failure when my tests pass. So I think that this implementation of expectedFailures is a hack. Adrian On Apr 20, 2010, at 21:57 , Stéphane Ducasse wrote: Hi I tagged some tests as expected failures and I got a strange behavior. On the the tests which was passing was listed under the failures. When I renamed the method without updating the expected failures my bar was green. So expected failures really expect that the tests failed? We cannto have green tests in there? 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 ___ 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 -- www.tudorgirba.com Live like you mean it. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] what expectedfailures expected to do?
We should have a look at what adrian did now the problem is that understanding a large set of changes is more difficult than a couple of simple ones. If somebody want to help we are open. Stef I think Adrian Kuhn did that in his SUnit work. I also remember he also introduced a difference between expectedFailures and expectedErrors. Doru On 21 Apr 2010, at 10:16, Stéphane Ducasse wrote: On Apr 21, 2010, at 9:51 AM, Adrian Lienhard wrote: Yea, I agree, the GUI is suboptimal. I still think, though, that treating this case as a failure is correct. For instance, consider the case where you had added a workaround to a known bug and when the bug is fixed you need to remove the workaround again. Maybe it even leads to a wrong behavior now that the bug is gone. In this case you really want to know that the test does not fail anymore. yes Now I have the impression that expectedFailures should be like passes, failed, errors: a state of the tests. Stef In any case, I think that tagging methods as expected failures should be done with pragmas and not with #expectedFailures. Like this it would also be much easier to understand what's going on when you have a failure in this test although all assertions pass. Adrian On Apr 21, 2010, at 08:22 , Stéphane Ducasse wrote: On Apr 20, 2010, at 11:20 PM, Adrian Lienhard wrote: Yes, if a test that is expected to fail does not fail, this is treated as a failure. I think that makes sense. well it depends about the scenario. you put on expectedfailures something that gets in your way now, so after if it works even better. of course you should get notified that the test is green while expected it to failed. Now it leads to a UI problem where you have a failure that passes so when you click on it nothing happens: no debugger. And you can wonder why the hell do I have a failure when my tests pass. So I think that this implementation of expectedFailures is a hack. Adrian On Apr 20, 2010, at 21:57 , Stéphane Ducasse wrote: Hi I tagged some tests as expected failures and I got a strange behavior. On the the tests which was passing was listed under the failures. When I renamed the method without updating the expected failures my bar was green. So expected failures really expect that the tests failed? We cannto have green tests in there? 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 ___ 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 -- www.tudorgirba.com Live like you mean it. ___ 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] what expectedfailures expected to do?
I'm trying to follow along with this discussion, but now I feel really stupid :-( I've been using SUnit since 1998 (when it was still called BeckTestingFramework), and ever since expected failures showed up, I've never understood them. So I wonder if some kind guru-like person could please explain to me what they are useful for? I mean, to my way of thinking, if one writes a test that is expected to fail, then why not invert the test and call it a success instead? for example: self should: [answer = 42] ...as an expected failure could simply be re-written as self should: [answer ~= 42] ...right? No, obviously I've missed something really obvious and important, and that's why I'm asking the question now. Please be gentle ;-) -- Cheers, Peter On Wed, Apr 21, 2010 at 10:30 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: We should have a look at what adrian did now the problem is that understanding a large set of changes is more difficult than a couple of simple ones. If somebody want to help we are open. Stef I think Adrian Kuhn did that in his SUnit work. I also remember he also introduced a difference between expectedFailures and expectedErrors. Doru On 21 Apr 2010, at 10:16, Stéphane Ducasse wrote: On Apr 21, 2010, at 9:51 AM, Adrian Lienhard wrote: Yea, I agree, the GUI is suboptimal. I still think, though, that treating this case as a failure is correct. For instance, consider the case where you had added a workaround to a known bug and when the bug is fixed you need to remove the workaround again. Maybe it even leads to a wrong behavior now that the bug is gone. In this case you really want to know that the test does not fail anymore. yes Now I have the impression that expectedFailures should be like passes, failed, errors: a state of the tests. Stef In any case, I think that tagging methods as expected failures should be done with pragmas and not with #expectedFailures. Like this it would also be much easier to understand what's going on when you have a failure in this test although all assertions pass. Adrian On Apr 21, 2010, at 08:22 , Stéphane Ducasse wrote: On Apr 20, 2010, at 11:20 PM, Adrian Lienhard wrote: Yes, if a test that is expected to fail does not fail, this is treated as a failure. I think that makes sense. well it depends about the scenario. you put on expectedfailures something that gets in your way now, so after if it works even better. of course you should get notified that the test is green while expected it to failed. Now it leads to a UI problem where you have a failure that passes so when you click on it nothing happens: no debugger. And you can wonder why the hell do I have a failure when my tests pass. So I think that this implementation of expectedFailures is a hack. Adrian On Apr 20, 2010, at 21:57 , Stéphane Ducasse wrote: Hi I tagged some tests as expected failures and I got a strange behavior. On the the tests which was passing was listed under the failures. When I renamed the method without updating the expected failures my bar was green. So expected failures really expect that the tests failed? We cannto have green tests in there? 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 ___ 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 -- www.tudorgirba.com Live like you mean it. ___ 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] what expectedfailures expected to do?
Hi, The idea behind this is that you can use unit tests to document things you have not done yet, or bugs that you know about but you do not want to spend time working on right now. Simply reverting the assertion in your test does make the test runner green, but it fails to document the intention, and a newcomer might get to the false conclusion that the answer is not 42. By marking the test as expected failure, you make the test runner green, but you also explicitly say that the answer should be 42, but the machine is not quite perfect yet. Cheers, Doru On 21 Apr 2010, at 11:06, Peter Hugosson-Miller wrote: I'm trying to follow along with this discussion, but now I feel really stupid :-( I've been using SUnit since 1998 (when it was still called BeckTestingFramework), and ever since expected failures showed up, I've never understood them. So I wonder if some kind guru-like person could please explain to me what they are useful for? I mean, to my way of thinking, if one writes a test that is expected to fail, then why not invert the test and call it a success instead? for example: self should: [answer = 42] ...as an expected failure could simply be re-written as self should: [answer ~= 42] ...right? No, obviously I've missed something really obvious and important, and that's why I'm asking the question now. Please be gentle ;-) -- Cheers, Peter On Wed, Apr 21, 2010 at 10:30 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: We should have a look at what adrian did now the problem is that understanding a large set of changes is more difficult than a couple of simple ones. If somebody want to help we are open. Stef I think Adrian Kuhn did that in his SUnit work. I also remember he also introduced a difference between expectedFailures and expectedErrors. Doru On 21 Apr 2010, at 10:16, Stéphane Ducasse wrote: On Apr 21, 2010, at 9:51 AM, Adrian Lienhard wrote: Yea, I agree, the GUI is suboptimal. I still think, though, that treating this case as a failure is correct. For instance, consider the case where you had added a workaround to a known bug and when the bug is fixed you need to remove the workaround again. Maybe it even leads to a wrong behavior now that the bug is gone. In this case you really want to know that the test does not fail anymore. yes Now I have the impression that expectedFailures should be like passes, failed, errors: a state of the tests. Stef In any case, I think that tagging methods as expected failures should be done with pragmas and not with #expectedFailures. Like this it would also be much easier to understand what's going on when you have a failure in this test although all assertions pass. Adrian On Apr 21, 2010, at 08:22 , Stéphane Ducasse wrote: On Apr 20, 2010, at 11:20 PM, Adrian Lienhard wrote: Yes, if a test that is expected to fail does not fail, this is treated as a failure. I think that makes sense. well it depends about the scenario. you put on expectedfailures something that gets in your way now, so after if it works even better. of course you should get notified that the test is green while expected it to failed. Now it leads to a UI problem where you have a failure that passes so when you click on it nothing happens: no debugger. And you can wonder why the hell do I have a failure when my tests pass. So I think that this implementation of expectedFailures is a hack. Adrian On Apr 20, 2010, at 21:57 , Stéphane Ducasse wrote: Hi I tagged some tests as expected failures and I got a strange behavior. On the the tests which was passing was listed under the failures. When I renamed the method without updating the expected failures my bar was green. So expected failures really expect that the tests failed? We cannto have green tests in there? 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 ___ 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 -- www.tudorgirba.com Live like you mean it. ___ Pharo-project mailing list
Re: [Pharo-project] what expectedfailures expected to do?
Thanks for answering, Doru! So if I've understood you correctly, expected failures are useful when one wants to give some code to someone else, with all the tests running green, but at the same time let that person know that some specific tests are really still red, but known about. In other words, are they simply a way of documenting work in progress, and not for production code? -- Cheers, Peter On Wed, Apr 21, 2010 at 11:12 AM, Tudor Girba tudor.gi...@gmail.com wrote: Hi, The idea behind this is that you can use unit tests to document things you have not done yet, or bugs that you know about but you do not want to spend time working on right now. Simply reverting the assertion in your test does make the test runner green, but it fails to document the intention, and a newcomer might get to the false conclusion that the answer is not 42. By marking the test as expected failure, you make the test runner green, but you also explicitly say that the answer should be 42, but the machine is not quite perfect yet. Cheers, Doru On 21 Apr 2010, at 11:06, Peter Hugosson-Miller wrote: I'm trying to follow along with this discussion, but now I feel really stupid :-( I've been using SUnit since 1998 (when it was still called BeckTestingFramework), and ever since expected failures showed up, I've never understood them. So I wonder if some kind guru-like person could please explain to me what they are useful for? I mean, to my way of thinking, if one writes a test that is expected to fail, then why not invert the test and call it a success instead? for example: self should: [answer = 42] ...as an expected failure could simply be re-written as self should: [answer ~= 42] ...right? No, obviously I've missed something really obvious and important, and that's why I'm asking the question now. Please be gentle ;-) -- Cheers, Peter On Wed, Apr 21, 2010 at 10:30 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: We should have a look at what adrian did now the problem is that understanding a large set of changes is more difficult than a couple of simple ones. If somebody want to help we are open. Stef I think Adrian Kuhn did that in his SUnit work. I also remember he also introduced a difference between expectedFailures and expectedErrors. Doru On 21 Apr 2010, at 10:16, Stéphane Ducasse wrote: On Apr 21, 2010, at 9:51 AM, Adrian Lienhard wrote: Yea, I agree, the GUI is suboptimal. I still think, though, that treating this case as a failure is correct. For instance, consider the case where you had added a workaround to a known bug and when the bug is fixed you need to remove the workaround again. Maybe it even leads to a wrong behavior now that the bug is gone. In this case you really want to know that the test does not fail anymore. yes Now I have the impression that expectedFailures should be like passes, failed, errors: a state of the tests. Stef In any case, I think that tagging methods as expected failures should be done with pragmas and not with #expectedFailures. Like this it would also be much easier to understand what's going on when you have a failure in this test although all assertions pass. Adrian On Apr 21, 2010, at 08:22 , Stéphane Ducasse wrote: On Apr 20, 2010, at 11:20 PM, Adrian Lienhard wrote: Yes, if a test that is expected to fail does not fail, this is treated as a failure. I think that makes sense. well it depends about the scenario. you put on expectedfailures something that gets in your way now, so after if it works even better. of course you should get notified that the test is green while expected it to failed. Now it leads to a UI problem where you have a failure that passes so when you click on it nothing happens: no debugger. And you can wonder why the hell do I have a failure when my tests pass. So I think that this implementation of expectedFailures is a hack. Adrian On Apr 20, 2010, at 21:57 , Stéphane Ducasse wrote: Hi I tagged some tests as expected failures and I got a strange behavior. On the the tests which was passing was listed under the failures. When I renamed the method without updating the expected failures my bar was green. So expected failures really expect that the tests failed? We cannto have green tests in there? 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] what expectedfailures expected to do?
Basically yes. It's not just for giving it to someone else, but also for yourself. The idea is to quickly notice when tests change color (from green to red), so instead of remembering how many failed before and comparing with the current number of failures, you simply mark them as expected failures and your bar becomes green. Doru On 21 Apr 2010, at 11:28, Peter Hugosson-Miller wrote: Thanks for answering, Doru! So if I've understood you correctly, expected failures are useful when one wants to give some code to someone else, with all the tests running green, but at the same time let that person know that some specific tests are really still red, but known about. In other words, are they simply a way of documenting work in progress, and not for production code? -- Cheers, Peter On Wed, Apr 21, 2010 at 11:12 AM, Tudor Girba tudor.gi...@gmail.com wrote: Hi, The idea behind this is that you can use unit tests to document things you have not done yet, or bugs that you know about but you do not want to spend time working on right now. Simply reverting the assertion in your test does make the test runner green, but it fails to document the intention, and a newcomer might get to the false conclusion that the answer is not 42. By marking the test as expected failure, you make the test runner green, but you also explicitly say that the answer should be 42, but the machine is not quite perfect yet. Cheers, Doru On 21 Apr 2010, at 11:06, Peter Hugosson-Miller wrote: I'm trying to follow along with this discussion, but now I feel really stupid :-( I've been using SUnit since 1998 (when it was still called BeckTestingFramework), and ever since expected failures showed up, I've never understood them. So I wonder if some kind guru-like person could please explain to me what they are useful for? I mean, to my way of thinking, if one writes a test that is expected to fail, then why not invert the test and call it a success instead? for example: self should: [answer = 42] ...as an expected failure could simply be re-written as self should: [answer ~= 42] ...right? No, obviously I've missed something really obvious and important, and that's why I'm asking the question now. Please be gentle ;-) -- Cheers, Peter On Wed, Apr 21, 2010 at 10:30 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: We should have a look at what adrian did now the problem is that understanding a large set of changes is more difficult than a couple of simple ones. If somebody want to help we are open. Stef I think Adrian Kuhn did that in his SUnit work. I also remember he also introduced a difference between expectedFailures and expectedErrors. Doru On 21 Apr 2010, at 10:16, Stéphane Ducasse wrote: On Apr 21, 2010, at 9:51 AM, Adrian Lienhard wrote: Yea, I agree, the GUI is suboptimal. I still think, though, that treating this case as a failure is correct. For instance, consider the case where you had added a workaround to a known bug and when the bug is fixed you need to remove the workaround again. Maybe it even leads to a wrong behavior now that the bug is gone. In this case you really want to know that the test does not fail anymore. yes Now I have the impression that expectedFailures should be like passes, failed, errors: a state of the tests. Stef In any case, I think that tagging methods as expected failures should be done with pragmas and not with #expectedFailures. Like this it would also be much easier to understand what's going on when you have a failure in this test although all assertions pass. Adrian On Apr 21, 2010, at 08:22 , Stéphane Ducasse wrote: On Apr 20, 2010, at 11:20 PM, Adrian Lienhard wrote: Yes, if a test that is expected to fail does not fail, this is treated as a failure. I think that makes sense. well it depends about the scenario. you put on expectedfailures something that gets in your way now, so after if it works even better. of course you should get notified that the test is green while expected it to failed. Now it leads to a UI problem where you have a failure that passes so when you click on it nothing happens: no debugger. And you can wonder why the hell do I have a failure when my tests pass. So I think that this implementation of expectedFailures is a hack. Adrian On Apr 20, 2010, at 21:57 , Stéphane Ducasse wrote: Hi I tagged some tests as expected failures and I got a strange behavior. On the the tests which was passing was listed under the failures. When I renamed the method without updating the expected failures my bar was green. So expected failures really expect that the tests failed? We cannto have green tests in there? Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr
Re: [Pharo-project] what expectedfailures expected to do?
On Wed, Apr 21, 2010 at 11:34 AM, Tudor Girba tudor.gi...@gmail.com wrote: Basically yes. It's not just for giving it to someone else, but also for yourself. The idea is to quickly notice when tests change color (from green to red), so instead of remembering how many failed before and comparing with the current number of failures, you simply mark them as expected failures and your bar becomes green. Thanks, I think I get it now. So really, I shouldn't expect to see any expected failures in Pharo 1.0, but since Pharo 1.1 is still in alpha, it would be OK to have some there until it's ready for release. -- Cheers, Peter Doru On 21 Apr 2010, at 11:28, Peter Hugosson-Miller wrote: Thanks for answering, Doru! So if I've understood you correctly, expected failures are useful when one wants to give some code to someone else, with all the tests running green, but at the same time let that person know that some specific tests are really still red, but known about. In other words, are they simply a way of documenting work in progress, and not for production code? -- Cheers, Peter On Wed, Apr 21, 2010 at 11:12 AM, Tudor Girba tudor.gi...@gmail.com wrote: Hi, The idea behind this is that you can use unit tests to document things you have not done yet, or bugs that you know about but you do not want to spend time working on right now. Simply reverting the assertion in your test does make the test runner green, but it fails to document the intention, and a newcomer might get to the false conclusion that the answer is not 42. By marking the test as expected failure, you make the test runner green, but you also explicitly say that the answer should be 42, but the machine is not quite perfect yet. Cheers, Doru On 21 Apr 2010, at 11:06, Peter Hugosson-Miller wrote: I'm trying to follow along with this discussion, but now I feel really stupid :-( I've been using SUnit since 1998 (when it was still called BeckTestingFramework), and ever since expected failures showed up, I've never understood them. So I wonder if some kind guru-like person could please explain to me what they are useful for? I mean, to my way of thinking, if one writes a test that is expected to fail, then why not invert the test and call it a success instead? for example: self should: [answer = 42] ...as an expected failure could simply be re-written as self should: [answer ~= 42] ...right? No, obviously I've missed something really obvious and important, and that's why I'm asking the question now. Please be gentle ;-) -- Cheers, Peter On Wed, Apr 21, 2010 at 10:30 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: We should have a look at what adrian did now the problem is that understanding a large set of changes is more difficult than a couple of simple ones. If somebody want to help we are open. Stef I think Adrian Kuhn did that in his SUnit work. I also remember he also introduced a difference between expectedFailures and expectedErrors. Doru On 21 Apr 2010, at 10:16, Stéphane Ducasse wrote: On Apr 21, 2010, at 9:51 AM, Adrian Lienhard wrote: Yea, I agree, the GUI is suboptimal. I still think, though, that treating this case as a failure is correct. For instance, consider the case where you had added a workaround to a known bug and when the bug is fixed you need to remove the workaround again. Maybe it even leads to a wrong behavior now that the bug is gone. In this case you really want to know that the test does not fail anymore. yes Now I have the impression that expectedFailures should be like passes, failed, errors: a state of the tests. Stef In any case, I think that tagging methods as expected failures should be done with pragmas and not with #expectedFailures. Like this it would also be much easier to understand what's going on when you have a failure in this test although all assertions pass. Adrian On Apr 21, 2010, at 08:22 , Stéphane Ducasse wrote: On Apr 20, 2010, at 11:20 PM, Adrian Lienhard wrote: Yes, if a test that is expected to fail does not fail, this is treated as a failure. I think that makes sense. well it depends about the scenario. you put on expectedfailures something that gets in your way now, so after if it works even better. of course you should get notified that the test is green while expected it to failed. Now it leads to a UI problem where you have a failure that passes so when you click on it nothing happens: no debugger. And you can wonder why the hell do I have a failure when my tests pass. So I think that this implementation of expectedFailures is a hack. Adrian On Apr 20, 2010, at 21:57 , Stéphane Ducasse wrote: Hi I tagged some tests as expected failures and I got a strange behavior. On the the tests which was passing was listed under the failures. When I renamed the method without updating the expected
Re: [Pharo-project] [Vm-dev] Running Alien on Windows
On Tue, Apr 20, 2010 at 09:23:36PM -0700, Andreas Raab wrote: On 4/20/2010 10:24 AM, Torsten Bergmann wrote: Dont know what should be the next steps to get Alien into the Win32-VM code base. Maybe Andreas could tell you more. Perhaps David and/or Eliot can help? From my perspective this issue doesn't really belong with the Windows VM but rather with the VMMaker package. I just build whatever is in there, so if Alien support is in, then I'll build it together with everything else. Cheers, - Andreas Yes, I'll be glad to help. I'll look at it as soon as possible (probably not until this weekend though). Dave [1] http://lists.squeakfoundation.org/pipermail/vm-dev/2010-March/003983.html [2] http://code.google.com/p/pharo/issues/detail?id=1360 [3] http://bugs.squeak.org/view.php?id=7475 [4] http://lists.squeakfoundation.org/pipermail/vm-dev/2010-March/004034.html [5] http://lists.squeakfoundation.org/pipermail/vm-dev/2010-March/004037.html [6] http://lists.squeakfoundation.org/pipermail/vm-dev/2010-March/004054.html [7] http://lists.squeakfoundation.org/pipermail/vm-dev/2010- March/004103.html ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] FEATURE: User chooses preferred location for MC directory repositories
Here http://book.pharo-project.org/book/TipsAndTricks/PharoRC Can someone adapt it for Windows ? Cheers, Laurent Laffont On Wed, Apr 21, 2010 at 8:56 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: Cool I will do that too. Can you create a book entry with that because this is cool :) Stef On Apr 21, 2010, at 8:40 AM, laurent laffont wrote: On Tue, Apr 20, 2010 at 11:21 PM, Michael Roberts m...@mjr104.co.uk wrote: i'm not sure what either of you mean. I want there to be no UI choice and the system just looks higher up in the file system hierarchy. certainly environment variables or a .pharorc style file would solve this. On my machine I've written these files: ~/.pharorc.st Author fullName: 'LaurentLaffont'. MCRepositoryGroup default addRepository: (MCDirectoryRepository new directory: (FileDirectory on: '/home/laurent/pharo/repository')). Then ~/bin/pharo: #!/bin/sh squeak $1 ~/.pharorc.st Then I launch my image with: pharo /path/to/my.image Author and repository always set for every image. Very emacs-like :) Cheers, Laurent Laffont thanks, Mike On Tue, Apr 20, 2010 at 6:33 PM, Chris Muller asquea...@gmail.com wrote: Whether the user is required to specify a default directory or a directory to a repository, it's the same task isn't it? Once you add it once to MC, it can be added to any other package. So this defaultDirectory would seem to be a feature not worth its weight.. On Mon, Apr 19, 2010 at 6:00 PM, Sean P. DeNigris s...@clipperadams.com wrote: http://code.google.com/p/pharo/issues/detail?id=2329 Pharo image: Pharo 1.0 In Monticello Browser, when I click +Repository and select directory, I'd love to be taken right to the directory where I keep my local repositories, instead of having to click to the same place over and over. I changed the following method: MCDirectoryRepository classmorphicConfigure ^ (UIManager default chooseDirectoryFrom: (FileDirectory on: '/path/to/my/Repositories')) ifNotNil: [:directory | self new directory: directory] How should I store the default repository directory? Would anyone else find this helpful? Sean DeNigris -- View this message in context: http://n4.nabble.com/FEATURE-User-chooses-preferred-location-for-MC-directory-repositories-tp2016684p2016684.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 ___ 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] what expectedfailures expected to do?
On Apr 21, 2010, at 11:06 AM, Peter Hugosson-Miller wrote: I'm trying to follow along with this discussion, but now I feel really stupid :-( I've been using SUnit since 1998 (when it was still called BeckTestingFramework), testingFramework on VW :) and ever since expected failures showed up, I've never understood them. So I wonder if some kind guru-like person could please explain to me what they are useful for? I mean, to my way of thinking, if one writes a test that is expected to fail, then why not invert the test and call it a success instead? for example: self should: [answer = 42] self assert: answer = 42 because [] are for self should: [] raise: Error and friend ...as an expected failure could simply be re-written as self should: [answer ~= 42] ...right? No, obviously I've missed something really obvious and important, and that's why I'm asking the question now. Please be gentle ;-) -- Cheers, Peter On Wed, Apr 21, 2010 at 10:30 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: We should have a look at what adrian did now the problem is that understanding a large set of changes is more difficult than a couple of simple ones. If somebody want to help we are open. Stef I think Adrian Kuhn did that in his SUnit work. I also remember he also introduced a difference between expectedFailures and expectedErrors. Doru On 21 Apr 2010, at 10:16, Stéphane Ducasse wrote: On Apr 21, 2010, at 9:51 AM, Adrian Lienhard wrote: Yea, I agree, the GUI is suboptimal. I still think, though, that treating this case as a failure is correct. For instance, consider the case where you had added a workaround to a known bug and when the bug is fixed you need to remove the workaround again. Maybe it even leads to a wrong behavior now that the bug is gone. In this case you really want to know that the test does not fail anymore. yes Now I have the impression that expectedFailures should be like passes, failed, errors: a state of the tests. Stef In any case, I think that tagging methods as expected failures should be done with pragmas and not with #expectedFailures. Like this it would also be much easier to understand what's going on when you have a failure in this test although all assertions pass. Adrian On Apr 21, 2010, at 08:22 , Stéphane Ducasse wrote: On Apr 20, 2010, at 11:20 PM, Adrian Lienhard wrote: Yes, if a test that is expected to fail does not fail, this is treated as a failure. I think that makes sense. well it depends about the scenario. you put on expectedfailures something that gets in your way now, so after if it works even better. of course you should get notified that the test is green while expected it to failed. Now it leads to a UI problem where you have a failure that passes so when you click on it nothing happens: no debugger. And you can wonder why the hell do I have a failure when my tests pass. So I think that this implementation of expectedFailures is a hack. Adrian On Apr 20, 2010, at 21:57 , Stéphane Ducasse wrote: Hi I tagged some tests as expected failures and I got a strange behavior. On the the tests which was passing was listed under the failures. When I renamed the method without updating the expected failures my bar was green. So expected failures really expect that the tests failed? We cannto have green tests in there? 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 ___ 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 -- www.tudorgirba.com Live like you mean it. ___ 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
Re: [Pharo-project] what expectedfailures expected to do?
On Apr 21, 2010, at 11:47 AM, Peter Hugosson-Miller wrote: On Wed, Apr 21, 2010 at 11:34 AM, Tudor Girba tudor.gi...@gmail.com wrote: Basically yes. It's not just for giving it to someone else, but also for yourself. The idea is to quickly notice when tests change color (from green to red), so instead of remembering how many failed before and comparing with the current number of failures, you simply mark them as expected failures and your bar becomes green. Thanks, I think I get it now. So really, I shouldn't expect to see any expected failures in Pharo 1.0, but since Pharo 1.1 is still in alpha, it would be OK to have some there until it's ready for release. in a perfect world now in pharo we have tests that are red and we could not fixed easily. -- Cheers, Peter Doru On 21 Apr 2010, at 11:28, Peter Hugosson-Miller wrote: Thanks for answering, Doru! So if I've understood you correctly, expected failures are useful when one wants to give some code to someone else, with all the tests running green, but at the same time let that person know that some specific tests are really still red, but known about. In other words, are they simply a way of documenting work in progress, and not for production code? -- Cheers, Peter On Wed, Apr 21, 2010 at 11:12 AM, Tudor Girba tudor.gi...@gmail.com wrote: Hi, The idea behind this is that you can use unit tests to document things you have not done yet, or bugs that you know about but you do not want to spend time working on right now. Simply reverting the assertion in your test does make the test runner green, but it fails to document the intention, and a newcomer might get to the false conclusion that the answer is not 42. By marking the test as expected failure, you make the test runner green, but you also explicitly say that the answer should be 42, but the machine is not quite perfect yet. Cheers, Doru On 21 Apr 2010, at 11:06, Peter Hugosson-Miller wrote: I'm trying to follow along with this discussion, but now I feel really stupid :-( I've been using SUnit since 1998 (when it was still called BeckTestingFramework), and ever since expected failures showed up, I've never understood them. So I wonder if some kind guru-like person could please explain to me what they are useful for? I mean, to my way of thinking, if one writes a test that is expected to fail, then why not invert the test and call it a success instead? for example: self should: [answer = 42] ...as an expected failure could simply be re-written as self should: [answer ~= 42] ...right? No, obviously I've missed something really obvious and important, and that's why I'm asking the question now. Please be gentle ;-) -- Cheers, Peter On Wed, Apr 21, 2010 at 10:30 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: We should have a look at what adrian did now the problem is that understanding a large set of changes is more difficult than a couple of simple ones. If somebody want to help we are open. Stef I think Adrian Kuhn did that in his SUnit work. I also remember he also introduced a difference between expectedFailures and expectedErrors. Doru On 21 Apr 2010, at 10:16, Stéphane Ducasse wrote: On Apr 21, 2010, at 9:51 AM, Adrian Lienhard wrote: Yea, I agree, the GUI is suboptimal. I still think, though, that treating this case as a failure is correct. For instance, consider the case where you had added a workaround to a known bug and when the bug is fixed you need to remove the workaround again. Maybe it even leads to a wrong behavior now that the bug is gone. In this case you really want to know that the test does not fail anymore. yes Now I have the impression that expectedFailures should be like passes, failed, errors: a state of the tests. Stef In any case, I think that tagging methods as expected failures should be done with pragmas and not with #expectedFailures. Like this it would also be much easier to understand what's going on when you have a failure in this test although all assertions pass. Adrian On Apr 21, 2010, at 08:22 , Stéphane Ducasse wrote: On Apr 20, 2010, at 11:20 PM, Adrian Lienhard wrote: Yes, if a test that is expected to fail does not fail, this is treated as a failure. I think that makes sense. well it depends about the scenario. you put on expectedfailures something that gets in your way now, so after if it works even better. of course you should get notified that the test is green while expected it to failed. Now it leads to a UI problem where you have a failure that passes so when you click on it nothing happens: no debugger. And you can wonder why the hell do I have a failure when my tests pass. So I think that this implementation of expectedFailures is a hack. Adrian On Apr 20, 2010, at 21:57 ,
Re: [Pharo-project] FEATURE: User chooses preferred location for MC directory repositories
cool! On Apr 21, 2010, at 1:26 PM, laurent laffont wrote: Here http://book.pharo-project.org/book/TipsAndTricks/PharoRC Can someone adapt it for Windows ? Cheers, Laurent Laffont On Wed, Apr 21, 2010 at 8:56 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: Cool I will do that too. Can you create a book entry with that because this is cool :) Stef On Apr 21, 2010, at 8:40 AM, laurent laffont wrote: On Tue, Apr 20, 2010 at 11:21 PM, Michael Roberts m...@mjr104.co.uk wrote: i'm not sure what either of you mean. I want there to be no UI choice and the system just looks higher up in the file system hierarchy. certainly environment variables or a .pharorc style file would solve this. On my machine I've written these files: ~/.pharorc.st Author fullName: 'LaurentLaffont'. MCRepositoryGroup default addRepository: (MCDirectoryRepository new directory: (FileDirectory on: '/home/laurent/pharo/repository')). Then ~/bin/pharo: #!/bin/sh squeak $1 ~/.pharorc.st Then I launch my image with: pharo /path/to/my.image Author and repository always set for every image. Very emacs-like :) Cheers, Laurent Laffont thanks, Mike On Tue, Apr 20, 2010 at 6:33 PM, Chris Muller asquea...@gmail.com wrote: Whether the user is required to specify a default directory or a directory to a repository, it's the same task isn't it? Once you add it once to MC, it can be added to any other package. So this defaultDirectory would seem to be a feature not worth its weight.. On Mon, Apr 19, 2010 at 6:00 PM, Sean P. DeNigris s...@clipperadams.com wrote: http://code.google.com/p/pharo/issues/detail?id=2329 Pharo image: Pharo 1.0 In Monticello Browser, when I click +Repository and select directory, I'd love to be taken right to the directory where I keep my local repositories, instead of having to click to the same place over and over. I changed the following method: MCDirectoryRepository classmorphicConfigure ^ (UIManager default chooseDirectoryFrom: (FileDirectory on: '/path/to/my/Repositories')) ifNotNil: [:directory | self new directory: directory] How should I store the default repository directory? Would anyone else find this helpful? Sean DeNigris -- View this message in context: http://n4.nabble.com/FEATURE-User-chooses-preferred-location-for-MC-directory-repositories-tp2016684p2016684.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 ___ 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] setting a custom header for HTTP via CurlPlugin
Hi, I am trying to get some stuff done with REST using Pharo. So far, I am able to do GETs, but I am unable to do PUTs because the REST service expects the content sent to be JSON. For this to work, I need to set the Content-Type of the request to 'application/json'. I have successfully installed the CurlPlugin via Gofer (version 25 from dao), and thanks to John (M. McIntosh), who provided me with a new version of the bundle for Mac, I was able to pass all the tests, except for the testApiOptions test, which fails on the timeout: test. The version John provided me with is 2.0.0. I first tried with version 1.1.0, but that failed on 13 tests due to a primitive that failed constantly (primitive: 'primSetOptLong' module: 'CurlPlugin'). There is a method addHeader: in the plugin, but it does not seem to do anything useful. I have found a blog (Jazz Programming) by Giovanni Corriga, who claims to have a version of the plugin that allows for custom headers to be set, but the link to his version gives a 304 error. Plus the blog dates from 2007. Having a version of the CurlPlugin that allows me to set a custom header would be great, so if anybody has one, please let me know. But what I would really like to have is a good implementation of the HTTP protocol in Squeak/Pharo, so that we are not dependent on a plugin. The standard HTTP client in Squeak/Pharo is based on HttpSocket, and is only a partial implementation of the HTTP protocol (it only supports GETs as far as I can tell). Does anyone know of another way to do basic HTTP in Squeak/Pharo? Regards, Hein ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] setting a custom header for HTTP via CurlPlugin
On Apr 21, 2010, at 1:48 PM, Saris Hein wrote: Hi, I am trying to get some stuff done with REST using Pharo. So far, I am able to do GETs, but I am unable to do PUTs because the REST service expects the content sent to be JSON. For this to work, I need to set the Content-Type of the request to 'application/json'. I have successfully installed the CurlPlugin via Gofer (version 25 from dao), and thanks to John (M. McIntosh), who provided me with a new version of the bundle for Mac, I was able to pass all the tests, except for the testApiOptions test, which fails on the timeout: test. The version John provided me with is 2.0.0. I first tried with version 1.1.0, but that failed on 13 tests due to a primitive that failed constantly (primitive: 'primSetOptLong' module: 'CurlPlugin'). There is a method addHeader: in the plugin, but it does not seem to do anything useful. I have found a blog (Jazz Programming) by Giovanni Corriga, who claims to have a version of the plugin that allows for custom headers to be set, but the link to his version gives a 304 error. Plus the blog dates from 2007. Having a version of the CurlPlugin that allows me to set a custom header would be great, so if anybody has one, please let me know. But what I would really like to have is a good implementation of the HTTP protocol in Squeak/Pharo, so that we are not dependent on a plugin. me too. Did you discuss with janko? Because he was proposing a project on exactly this topic. The standard HTTP client in Squeak/Pharo is based on HttpSocket, and is only a partial implementation of the HTTP protocol (it only supports GETs as far as I can tell). Does anyone know of another way to do basic HTTP in Squeak/Pharo? Regards, Hein ___ 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] what expectedfailures expected to do?
On Wed, Apr 21, 2010 at 1:37 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: On Apr 21, 2010, at 11:47 AM, Peter Hugosson-Miller wrote: On Wed, Apr 21, 2010 at 11:34 AM, Tudor Girba tudor.gi...@gmail.com wrote: Basically yes. It's not just for giving it to someone else, but also for yourself. The idea is to quickly notice when tests change color (from green to red), so instead of remembering how many failed before and comparing with the current number of failures, you simply mark them as expected failures and your bar becomes green. Thanks, I think I get it now. So really, I shouldn't expect to see any expected failures in Pharo 1.0, but since Pharo 1.1 is still in alpha, it would be OK to have some there until it's ready for release. in a perfect world now in pharo we have tests that are red and we could not fixed easily. Ah, OK. I guess it's really a question of perception. The world in which I work is a bit different from the wonderful world of Pharo (no sarcasm intended!), in that we can't ship *anything* unless *all* our tests are green. The concept of expected failures just has no place, because as long as there are failures we still have work to do. I can understand Doru's description of an expected failure as a kind of bookmark, to be added and discarded during the day, but I get a bit nervous that the sight of too much green might make me miss the fact that I'm not finished yet :-p -- Cheers, Peter Doru On 21 Apr 2010, at 11:28, Peter Hugosson-Miller wrote: Thanks for answering, Doru! So if I've understood you correctly, expected failures are useful when one wants to give some code to someone else, with all the tests running green, but at the same time let that person know that some specific tests are really still red, but known about. In other words, are they simply a way of documenting work in progress, and not for production code? -- Cheers, Peter On Wed, Apr 21, 2010 at 11:12 AM, Tudor Girba tudor.gi...@gmail.com wrote: Hi, The idea behind this is that you can use unit tests to document things you have not done yet, or bugs that you know about but you do not want to spend time working on right now. Simply reverting the assertion in your test does make the test runner green, but it fails to document the intention, and a newcomer might get to the false conclusion that the answer is not 42. By marking the test as expected failure, you make the test runner green, but you also explicitly say that the answer should be 42, but the machine is not quite perfect yet. Cheers, Doru On 21 Apr 2010, at 11:06, Peter Hugosson-Miller wrote: I'm trying to follow along with this discussion, but now I feel really stupid :-( I've been using SUnit since 1998 (when it was still called BeckTestingFramework), and ever since expected failures showed up, I've never understood them. So I wonder if some kind guru-like person could please explain to me what they are useful for? I mean, to my way of thinking, if one writes a test that is expected to fail, then why not invert the test and call it a success instead? for example: self should: [answer = 42] ...as an expected failure could simply be re-written as self should: [answer ~= 42] ...right? No, obviously I've missed something really obvious and important, and that's why I'm asking the question now. Please be gentle ;-) -- Cheers, Peter On Wed, Apr 21, 2010 at 10:30 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: We should have a look at what adrian did now the problem is that understanding a large set of changes is more difficult than a couple of simple ones. If somebody want to help we are open. Stef I think Adrian Kuhn did that in his SUnit work. I also remember he also introduced a difference between expectedFailures and expectedErrors. Doru On 21 Apr 2010, at 10:16, Stéphane Ducasse wrote: On Apr 21, 2010, at 9:51 AM, Adrian Lienhard wrote: Yea, I agree, the GUI is suboptimal. I still think, though, that treating this case as a failure is correct. For instance, consider the case where you had added a workaround to a known bug and when the bug is fixed you need to remove the workaround again. Maybe it even leads to a wrong behavior now that the bug is gone. In this case you really want to know that the test does not fail anymore. yes Now I have the impression that expectedFailures should be like passes, failed, errors: a state of the tests. Stef In any case, I think that tagging methods as expected failures should be done with pragmas and not with #expectedFailures. Like this it would also be much easier to understand what's going on when you have a failure in this test although all assertions pass. Adrian On Apr 21, 2010, at 08:22 , Stéphane Ducasse wrote: On Apr 20, 2010, at 11:20 PM,
Re: [Pharo-project] what expectedfailures expected to do?
Ah, OK. I guess it's really a question of perception. not perception. Just money. Give me three engineers full times during two years and you will not recognize pharo :) The world in which I work is a bit different from the wonderful world of Pharo (no sarcasm intended!), in that we can't ship *anything* unless *all* our tests are green. The concept of expected failures just has no place, because as long as there are failures we still have work to do. Oh this is easy we can remove tests and your customers will be happy :) Now some tests represents the semantics of blocclosure that no smalltalk truly implement, so this would be a pity to throw them away. I can understand Doru's description of an expected failure as a kind of bookmark, to be added and discarded during the day, but I get a bit nervous that the sight of too much green might make me miss the fact that I'm not finished yet :-p Exact this is why removing expected failures at the start of each cycle is the thing to do ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] setting a custom header for HTTP via CurlPlugin
The Cloudfork (amazon web services wrappers) guys propose two options: - SWHTTPClient - CurlPlugin I've never tested the former one, but you'll maybe find what you need ? http://code.google.com/p/cloudfork/wiki/InstallingForSqueak Having a version of the CurlPlugin that allows me to set a custom header would be great, so if anybody has one, please let me know. But what I would really like to have is a good implementation of the HTTP protocol in Squeak/Pharo, so that we are not dependent on a plugin. me too. Did you discuss with janko? Because he was proposing a project on exactly this topic. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] FEATURE: User chooses preferred location for MC directory repositories
I added this example in Monticello.tex, section repositories.
Thanks Dale!
Cheers,
Alexandre
On 21 Apr 2010, at 02:18, Stéphane Ducasse wrote:
we should add that to the pharo book :)
On Apr 21, 2010, at 2:42 AM, Dale Henrichs wrote:
Sean,
Don't know if this has already mentioned, but you can
programmatically add Directory repositories as follows:
| repo |
{'/path/to/repositories/project-1/'. '/path/to/repositories/
project-2/'.
'/path/to/repositories/project-3/'. } do: [:path |
repo := MCDirectoryRepository new directory:
(FileDirectory on: path).
MCRepositoryGroup default addRepository: repo ].
- Sean P. DeNigris s...@clipperadams.com wrote:
| I'll give you my use case:
| I share my projects among a few images, and I like to keep them in
| sub-
| directories like:
| /path/to/repositories/project-1/
| /path/to/repositories/project-2/
| /path/to/repositories/project-3/
| So each one of these is a separate, unrelated repository in a
common
|
| parent directory for ease of finding.
|
| So when I +Repository to each image, I have to navigate from the
| default directory to my repository for each new repository. If I
can
|
| pick a start directory once as a setting, I can add new project's
sub-
|
| directory or open them without any navigation.
|
| Does that make sense?
|
| Sean
|
| On Apr 20, 2010, at 1:33 PM, Chris Muller-3 [via Smalltalk]
| ml-node+2017760-613088063-217...@n4.nabble.com
| wrote:
|
| Whether the user is required to specify a default directory
or a
| directory to a repository, it's the same task isn't it?
|
| Once you add it once to MC, it can be added to any other
package.
| So this defaultDirectory would seem to be a feature not worth its
| weight..
|
|
| On Mon, Apr 19, 2010 at 6:00 PM, Sean P. DeNigris [hidden
email]
|
| wrote:
|
|
| http://code.google.com/p/pharo/issues/detail?id=2329
|
| Pharo image: Pharo 1.0
|
| In Monticello Browser, when I click +Repository and select
| directory,
| I'd love to be taken right to the directory where I keep my
local
| repositories, instead of having to click to the same place over
| and over.
|
| I changed the following method:
| MCDirectoryRepository classmorphicConfigure
| ^ (UIManager default chooseDirectoryFrom: (FileDirectory
| on:
| '/path/to/my/Repositories')) ifNotNil:
| [:directory |
| self new directory: directory]
|
| How should I store the default repository directory? Would
anyone
|
| else find
| this helpful?
|
| Sean DeNigris
| --
| View this message in context:
|
http://n4.nabble.com/FEATURE-User-chooses-preferred-location-for-MC-directory-repositories-tp2016684p2016684.html
| Sent from the Pharo Smalltalk mailing list archive at
Nabble.com.
|
| ___
| Pharo-project mailing list
| [hidden email]
|
| http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
|
|
| ___
| Pharo-project mailing list
| [hidden email]
| http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
|
| View message @
|
http://n4.nabble.com/FEATURE-User-chooses-preferred-location-for-MC-directory-repositories-tp2016684p2017760.html
| To unsubscribe from FEATURE: User chooses preferred location
for MC
|
| directory repositories, click here.
|
|
| --
| View this message in context:
|
http://n4.nabble.com/FEATURE-User-chooses-preferred-location-for-MC-directory-repositories-tp2016684p2018216.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
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
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] setting a custom header for HTTP via CurlPlugin
On 21 April 2010 14:48, Saris Hein h...@beta9.be wrote: Hi, I am trying to get some stuff done with REST using Pharo. So far, I am able to do GETs, but I am unable to do PUTs because the REST service expects the content sent to be JSON. For this to work, I need to set the Content-Type of the request to 'application/json'. I have successfully installed the CurlPlugin via Gofer (version 25 from dao), and thanks to John (M. McIntosh), who provided me with a new version of the bundle for Mac, I was able to pass all the tests, except for the testApiOptions test, which fails on the timeout: test. The version John provided me with is 2.0.0. I first tried with version 1.1.0, but that failed on 13 tests due to a primitive that failed constantly (primitive: 'primSetOptLong' module: 'CurlPlugin'). There is a method addHeader: in the plugin, but it does not seem to do anything useful. I have found a blog (Jazz Programming) by Giovanni Corriga, who claims to have a version of the plugin that allows for custom headers to be set, but the link to his version gives a 304 error. Plus the blog dates from 2007. Having a version of the CurlPlugin that allows me to set a custom header would be great, so if anybody has one, please let me know. But what I would really like to have is a good implementation of the HTTP protocol in Squeak/Pharo, so that we are not dependent on a plugin. The standard HTTP client in Squeak/Pharo is based on HttpSocket, and is only a partial implementation of the HTTP protocol (it only supports GETs as far as I can tell). Does anyone know of another way to do basic HTTP in Squeak/Pharo? Yes. I know :) Another way is to use sockets directly, without curl. This is way what i went for implementing a CouchDB interface for Pharo Squeak. With this way you can generate _any_ request header with any contents, without bothering, if some 3rd party plugin supports it or not. You can check it out here: MCHttpRepository location: 'http://www.squeaksource.com/SCouchDB' user: '' password: '' Regards, Hein ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] FEATURE: User chooses preferred location for MC directory repositories
Environment variables can be interrogated, at least in Linux (perhaps other OS's, I haven't tried), via OSProcess: OSProcess thisOSProcess environment Hope that helps.. On Tue, Apr 20, 2010 at 4:21 PM, Michael Roberts m...@mjr104.co.uk wrote: i'm not sure what either of you mean. I want there to be no UI choice and the system just looks higher up in the file system hierarchy. certainly environment variables or a .pharorc style file would solve this. thanks, Mike On Tue, Apr 20, 2010 at 6:33 PM, Chris Muller asquea...@gmail.com wrote: Whether the user is required to specify a default directory or a directory to a repository, it's the same task isn't it? Once you add it once to MC, it can be added to any other package. So this defaultDirectory would seem to be a feature not worth its weight.. On Mon, Apr 19, 2010 at 6:00 PM, Sean P. DeNigris s...@clipperadams.com wrote: http://code.google.com/p/pharo/issues/detail?id=2329 Pharo image: Pharo 1.0 In Monticello Browser, when I click +Repository and select directory, I'd love to be taken right to the directory where I keep my local repositories, instead of having to click to the same place over and over. I changed the following method: MCDirectoryRepository classmorphicConfigure ^ (UIManager default chooseDirectoryFrom: (FileDirectory on: '/path/to/my/Repositories')) ifNotNil: [:directory | self new directory: directory] How should I store the default repository directory? Would anyone else find this helpful? Sean DeNigris -- View this message in context: http://n4.nabble.com/FEATURE-User-chooses-preferred-location-for-MC-directory-repositories-tp2016684p2016684.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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Why does datedVersion appear in both SmalltalkImage and SystemVersion?
Why does datedVersion appear in both SmalltalkImage and SystemVersion? SmalltalkImage delegates to SystemVersion. Why have both? Sean -- View this message in context: http://n4.nabble.com/Why-does-datedVersion-appear-in-both-SmalltalkImage-and-SystemVersion-tp2019137p2019137.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] Hints and clues for a Pharo newb
Hi all, So it's time for me to stop lurking and do some stuff. However, although I am an experienced Smalltalk programmer (VisualAge Smalltalk continuously since 1995), I am a complete newb when it comes to Pharo and Squeak, it's hard to find my way around, and it's going to take me some time to get up to speed. I'm working on a small improvement to the testing framework, using ideas that I have found to be very useful in my daily job over the past 15 years. Note that I am doing this from scratch, so that I don't accidentally steal anything that I've done in my work, but I know how it all works in VisualAge, so I feel sure that I'll eventually be able to find the corresponding classes and methods in Pharo. What I would like are a few hints, clues and nudges in the right direction for scenarios and questions that I will describe in this thread. What I *don't* want are full-blown solutions, because then I won't learn anything. I hope that some kind souls will be able to give me a little help in the beginning that will eventually bring me up to speed and let me be productive. So to start with, one scenario and one question: 1) I want to find or write a method on Process that will print a stack trace onto a supplied Stream. Ideally I'd like to be able to decide the start and stop depth of the trace, so for example if I know that the top 4 stack frames will always be uninteresting, I would want to be able to write something like this: Processor activeProcess printStackFrom: 5 to: 15 on: aStream. 2) What *exactly* is thisContext? It appears to be a reserved word in Pharo, just like the familiar self, super, true, false, nil that are always reserved in Smalltalk. I'd also like to get an idea of what it's good for, and if anyone can describe it in terms of something that is in VisualAge, that would be nice too :-) BTW, if this is not the appropriate place for a thread like this, then please tell me where I should put it (politely, of course :-p) -- Cheers, Peter ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why does datedVersion appear in both SmalltalkImage and SystemVersion?
On Apr 21, 2010, at 5:21 40PM, Sean P. DeNigris wrote: Why does datedVersion appear in both SmalltalkImage and SystemVersion? SmalltalkImage delegates to SystemVersion. Why have both? Sean -- View this message in context: http://n4.nabble.com/Why-does-datedVersion-appear-in-both-SmalltalkImage-and-SystemVersion-tp2019137p2019137.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 Because of backwards compatability, and because some people still use/prefer Smalltalk datedVersion over SystemVersion datedVersion. 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] Hints and clues for a Pharo newb
Peter, Welcome aboard! IMHO, this is a fine place for the discussion that will hopefully result. Two links that I find useful are: http://dir.gmane.org/gmane.comp.lang.smalltalk.pharo.devel http://dir.gmane.org/gmane.comp.lang.smalltalk.squeak.general as they allow searching of the lists. Have you downloaded Pharo by Example? You might also want to get a print copy from Lulu. Learning your way around the Monticello GUI will be important. It has some quirks that I discovered the hard way; they should live in the pharo-dev archive above. In short, class categories/package names are case-sensitive, but you might have to remove the working copy of a package that somehow (your fault or not) picked up an undesired capitalization, e.g. ThisORThat vs. ThisOrThat before you can create the one you want. Method categoris (ab)used to package methods (*packageNameGoesHere) are apparently not case-sensitive. That's about all the damage I have time to do at the moment. What brings you to Pharo? We're glad to have you, but your thoughts on the system, what it does well, and what needs to improve could be helpful. Bill From: pharo-project-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Peter Hugosson-Miller Sent: Wednesday, April 21, 2010 11:09 AM To: Pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] Hints and clues for a Pharo newb Hi all, So it's time for me to stop lurking and do some stuff. However, although I am an experienced Smalltalk programmer (VisualAge Smalltalk continuously since 1995), I am a complete newb when it comes to Pharo and Squeak, it's hard to find my way around, and it's going to take me some time to get up to speed. I'm working on a small improvement to the testing framework, using ideas that I have found to be very useful in my daily job over the past 15 years. Note that I am doing this from scratch, so that I don't accidentally steal anything that I've done in my work, but I know how it all works in VisualAge, so I feel sure that I'll eventually be able to find the corresponding classes and methods in Pharo. What I would like are a few hints, clues and nudges in the right direction for scenarios and questions that I will describe in this thread. What I *don't* want are full-blown solutions, because then I won't learn anything. I hope that some kind souls will be able to give me a little help in the beginning that will eventually bring me up to speed and let me be productive. So to start with, one scenario and one question: 1) I want to find or write a method on Process that will print a stack trace onto a supplied Stream. Ideally I'd like to be able to decide the start and stop depth of the trace, so for example if I know that the top 4 stack frames will always be uninteresting, I would want to be able to write something like this: Processor activeProcess printStackFrom: 5 to: 15 on: aStream. 2) What *exactly* is thisContext? It appears to be a reserved word in Pharo, just like the familiar self, super, true, false, nil that are always reserved in Smalltalk. I'd also like to get an idea of what it's good for, and if anyone can describe it in terms of something that is in VisualAge, that would be nice too :-) BTW, if this is not the appropriate place for a thread like this, then please tell me where I should put it (politely, of course :-p) -- Cheers, Peter ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Some more dev on Polymorph for DrGeo
Known to work with Pharo 1.0. Someone asked for a more elaborated UI for DrGeo, here are some progresses in this polymorphization of DrGeo. In its latest Monticello package one can grab DrGeo at http://www.squeaksource.com/DrGeoII See enclosed screenshot for a quick view. To start a DrGeo instance, do a DrGeo new in a workspace and enjoy the UI. Beware, style tools does not work in the toolbar. It is also possible to use DrGeo as a service for Etoys when executing a DrGeo sample openInWorld It is also possible to load XML description of DrGeo 1.1 geometric sketch, if one is interested you can grab it at http://svn.gnome.org/viewvc/drgeo/trunk/examples/figures/ and load a sketch with a command: DrGeo newXml: path Beware sketch with embedded Scheme code will not work (just try) Working sketch: mercedes, euler-line, DrGeoII comes with a better interface for scripting with Smalltalk script, empower by the IDE, much nice than the former Scheme one. Elaborated demonstration at http://blog.ofset.org/hilaire/index.php?post/script-drgeo (automatic translation link with Google in a comment, at the end of the article) inline: drgeo-poly.png___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Hints and clues for a Pharo newb
thisContext reifies the activation contexts (if that is the exact way to describe it?). I don't believe you have it in VA. So you can just walk it. If you look for some of the fatal error handling logic you can see how the debug log is written out on crash containing the stack. Cheers mike On Wednesday, April 21, 2010, Peter Hugosson-Miller oldmanl...@gmail.com wrote: Hi all, So it's time for me to stop lurking and do some stuff. However, although I am an experienced Smalltalk programmer (VisualAge Smalltalk continuously since 1995), I am a complete newb when it comes to Pharo and Squeak, it's hard to find my way around, and it's going to take me some time to get up to speed. I'm working on a small improvement to the testing framework, using ideas that I have found to be very useful in my daily job over the past 15 years. Note that I am doing this from scratch, so that I don't accidentally steal anything that I've done in my work, but I know how it all works in VisualAge, so I feel sure that I'll eventually be able to find the corresponding classes and methods in Pharo. What I would like are a few hints, clues and nudges in the right direction for scenarios and questions that I will describe in this thread. What I *don't* want are full-blown solutions, because then I won't learn anything. I hope that some kind souls will be able to give me a little help in the beginning that will eventually bring me up to speed and let me be productive. So to start with, one scenario and one question: 1) I want to find or write a method on Process that will print a stack trace onto a supplied Stream. Ideally I'd like to be able to decide the start and stop depth of the trace, so for example if I know that the top 4 stack frames will always be uninteresting, I would want to be able to write something like this: Processor activeProcess printStackFrom: 5 to: 15 on: aStream. 2) What *exactly* is thisContext? It appears to be a reserved word in Pharo, just like the familiar self, super, true, false, nil that are always reserved in Smalltalk. I'd also like to get an idea of what it's good for, and if anyone can describe it in terms of something that is in VisualAge, that would be nice too :-) BTW, if this is not the appropriate place for a thread like this, then please tell me where I should put it (politely, of course :-p) -- Cheers, Peter ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Error when 'Loading 11313-Pha-CleaningCompilerTests...'
Henrik Johansen wrote: SqueakSource is currently down. We are sorry for the inconvenience and working on the problem. In the meantime you can still commit to a directory repository on your disk and later copy the versions to SqueakSource. Oh, thanks. I didn't do too much investigating, lol. And, maybe the error message could be better than 'Error: can''t find EOCD position.' Sean -- View this message in context: http://n4.nabble.com/Error-when-Loading-11313-Pha-CleaningCompilerTests-tp2016295p2019263.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] Doc about Coral?
Hi, I was wondering if there is some documentation about Coral? I would like to play a bit with it :) Cheers, Nico signature.asc Description: Ceci est une partie de message numériquement signée ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Hints and clues for a Pharo newb
On Apr 21, 2010, at 6:09 02PM, Peter Hugosson-Miller wrote: Hi all, So it's time for me to stop lurking and do some stuff. However, although I am an experienced Smalltalk programmer (VisualAge Smalltalk continuously since 1995), I am a complete newb when it comes to Pharo and Squeak, it's hard to find my way around, and it's going to take me some time to get up to speed. I'm working on a small improvement to the testing framework, using ideas that I have found to be very useful in my daily job over the past 15 years. Note that I am doing this from scratch, so that I don't accidentally steal anything that I've done in my work, but I know how it all works in VisualAge, so I feel sure that I'll eventually be able to find the corresponding classes and methods in Pharo. What I would like are a few hints, clues and nudges in the right direction for scenarios and questions that I will describe in this thread. What I *don't* want are full-blown solutions, because then I won't learn anything. I hope that some kind souls will be able to give me a little help in the beginning that will eventually bring me up to speed and let me be productive. So to start with, one scenario and one question: 1) I want to find or write a method on Process that will print a stack trace onto a supplied Stream. Ideally I'd like to be able to decide the start and stop depth of the trace, so for example if I know that the top 4 stack frames will always be uninteresting, I would want to be able to write something like this: Processor activeProcess printStackFrom: 5 to: 15 on: aStream. 2) What *exactly* is thisContext? It appears to be a reserved word in Pharo, just like the familiar self, super, true, false, nil that are always reserved in Smalltalk. I'd also like to get an idea of what it's good for, and if anyone can describe it in terms of something that is in VisualAge, that would be nice too :-) BTW, if this is not the appropriate place for a thread like this, then please tell me where I should put it (politely, of course :-p) -- Cheers, Peter I haven't used VA, but for instance, 2) allows you to write 1) as: Process printStackFrom: start to: end on: aStream ((thisContext stackOfSize: end) removeFirst: start; yourself ) do: [:each | each printOn: aStream. aStream nextPut: Character cr]. ;) 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] Some more dev on Polymorph for DrGeo
Just uploaded a latest snapshot for XMl support. Hilaire ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Hints and clues for a Pharo newb
2010/4/21 Peter Hugosson-Miller oldmanl...@gmail.com: Hi all, So it's time for me to stop lurking and do some stuff. However, although I am an experienced Smalltalk programmer (VisualAge Smalltalk continuously since 1995), I am a complete newb when it comes to Pharo and Squeak, it's hard to find my way around, and it's going to take me some time to get up to speed. I'm working on a small improvement to the testing framework, using ideas that I have found to be very useful in my daily job over the past 15 years. Note that I am doing this from scratch, so that I don't accidentally steal anything that I've done in my work, but I know how it all works in VisualAge, so I feel sure that I'll eventually be able to find the corresponding classes and methods in Pharo. What I would like are a few hints, clues and nudges in the right direction for scenarios and questions that I will describe in this thread. What I *don't* want are full-blown solutions, because then I won't learn anything. I hope that some kind souls will be able to give me a little help in the beginning that will eventually bring me up to speed and let me be productive. So to start with, one scenario and one question: 1) I want to find or write a method on Process that will print a stack trace onto a supplied Stream. Ideally I'd like to be able to decide the start and stop depth of the trace, so for example if I know that the top 4 stack frames will always be uninteresting, I would want to be able to write something like this: Processor activeProcess printStackFrom: 5 to: 15 on: aStream. 2) What *exactly* is thisContext? It appears to be a reserved word in Pharo, just like the familiar self, super, true, false, nil that are always reserved in Smalltalk. I'd also like to get an idea of what it's good for, and if anyone can describe it in terms of something that is in VisualAge, that would be nice too :-) thisContext is a special object for representing an activation in a stack frame in a stack-based VM. There are two kinds of contexts: Method Contexts and Block Contexts. Context creation is optimized in the VM in most Smalltalks, so it's only really created as an object in the environment (reified) when it's specifically needed through thisContext. You may emulate its usage in VisualAge writing something like [] homeContext and in a method it would be thisContext returns the context of the sender ^[] homeContext sender although with some limitations. There are several applications related with computational reflection (Reflective Programming, Meta-Programming, MOP, etc) which makes use of the current context. Cheers, Hernán BTW, if this is not the appropriate place for a thread like this, then please tell me where I should put it (politely, of course :-p) -- Cheers, Peter ___ 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] Error when 'Loading 11313-Pha-CleaningCompilerTests...'
On Apr 21, 2010, at 6:44 05PM, Sean P. DeNigris wrote: Henrik Johansen wrote: SqueakSource is currently down. We are sorry for the inconvenience and working on the problem. In the meantime you can still commit to a directory repository on your disk and later copy the versions to SqueakSource. Oh, thanks. I didn't do too much investigating, lol. And, maybe the error message could be better than 'Error: can''t find EOCD position.' Sean Well... I'm not a network specialist, but the following code looks kind of shady: HTTPSocket class httpGetDocument: url args: args accept: mimeType request: requestString *snip* a 400-series error sock responseCode first = $4 ifTrue: [^ header, aStream contents]. No idea how much existing code will break if you, say, raise an Exception there instead :) 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] Hints and clues for a Pharo newb
thisContext is a special object for representing an activation in a stack frame in a stack-based VM. Actually thisContext represents *the current* activation/stack-frame. foo: anObject ^ thisContext at: 1 is the same as foo: anObject ^ anObject There are two kinds of contexts: Method Contexts and Block Contexts. Actually in Pharo images there are only instances of MethodContext. Though you can ask the context if it comes from a block by sending the message #isExecutingBlock. Context creation is optimized in the VM in most Smalltalks, so it's only really created as an object in the environment (reified) when it's specifically needed through thisContext. In Pharo contexts are not reified like that. Stack-frames are actual objects at all times. However, for speed reasons, their creation and garbage-collection is optimized by the VM. Stack frames get automatically recycled if nobody refers to them. There are several applications related with computational reflection (Reflective Programming, Meta-Programming, MOP, etc) which makes use of the current context. Also: exception handling, generators, continuations, co-routines, ... For another fun use of thisContext check this Stack-Overflow question: http://stackoverflow.com/questions/2500483/is-there-a-way-in-a-message-only-language-to-define-a-whiletrue-message-without-r 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] HelpSystem (was Documentation Team)
To clearify a few things from my side on the discussion on squeak-dev: 1. HelpSystem is working, if ASCII is OK for now we can use it Pharo/Squeak - otherwise I would see it as an early preview. I have clear goals how it should look like in the next iterations. For this more patience is necessary. 2. HelpSystem is independent from where and how the actual information is stored (I think I demonstrated this with the IRC example, the books and the API help). 3. I hope to keep HelpSystem in sync for major Squeak distributions (Squeak, Pharo, Cuis, ...) The last additions from Hannes already broke the code in Pharo. Seems to be a Pharo issue this time http://code.google.com/p/pharo/issues/detail?id=2342 But please dont commit when it is only working in Squeak since my development environment is Pharo. 4. Yes, the content is currently ASCII but the design is prepared to add other types in future releases. A HelpTopic defines an ivar contents - currently referring to a string. I may add another ivar contentType in the future to handle/distinguish additionaly types (HTML, SqueaksRichText, Morphs/BookMorph, ...) 5. HelpSystem should not be limited to Squeak. It should also serve the case that when you write and deploy a commercial app in Squeak you may use it to provide help to your end user/customer 6. There are two types of help I see: A. SystemHelp: Help books/Tutorials/Manuals B. SystemReference: API Help, class comments HelpSystem is supporting both. I already wrote about the differences and details in http://lists.gforge.inria.fr/pipermail/pharo-project/2010-April/024857.html 7. I would really like to see support for HTML viewing in the image (HTMLViewMorph or so) - maybe based on Scamper to get a better viewer (headings, tables, ...) than the current plain text. If people want to contribute they should start right with this task. I know that Laurent already made Scamper loadable in Pharo, dont know about the state in Squeak. There is also another HTML browser with markup and CSS now available open source as MIT (WithStyle), I already mentioned this. http://www.cincomsmalltalk.com/userblogs/rowanb/blogView?showComments=trueprintTitle=Im_back..._but_SWS_isntentry=3364012145 8. I know that we now have discussions on which syntax (Wiki,...) to use for describing the contents. My answer is: it is important but I dont care (yet) since this discussion is useless until we have an HTML viewer (see 7.) and even when there are different syntax styles you can provides builders to transform them into HTML or other contentTypes afterwards. See the class HelpBuilder and subclasses. 9. If you want to write a book for SystemHelp (see 6.A) then the help system provides a class CustomHelp similar to TestCase in SUnit. This class is used to directly map book structures to the class hierarchy. The intention was to be able to create, store and manage these books directly with the usual Smalltalk tools. You can even restructure your book with the RefactoringBrowser. 10. If you want to write API help you (see 6.B) can contribute right now by commenting all the undocumented classes in the standard image. HelpSystem just queries these informations from the usual sources (class comments, ...). I would not change this or make it too complicated since this is what people are used too. I dont see more documented classes by introducing a special syntax (wiki or whatever) people have to learn/know about - so lets clean up documenting the classes first. 11. HelpSystem is able to get contents from external sources (see the IRC example) - but I would prefer that authoring/viewing could be done right from within the image. Even when the result is stored external afterwards. Look at my example books: I can view and change them right from the image and make them available to other images using Metacello/Squeaksource. Accessibility of docu (viewing and authoring) is the key to keep the system and docu in sync and up to date. External authoring mostly results in unmaintained docu (see the Squeak Swiki). 12. I thought again if it is ready to integrate into Pharo and Squeak. From all the discussions I would say it is too early. 13. If one wants the docu on the web the answer is easy: we can generate static files or serve them with Seaside. But I have no need for that right now, especially since this is already available in various forms. We can do many things (similar to Python, JavaDoc, you name it) But - let's do it step by step. As I said: - Someone working on a good HTML Viewer
Re: [Pharo-project] Talking to Steve Jobs about Scratch.
Morning, I've posted the letter I had posted to the Apple developer forums and sent to Steve Jobs at http://www.mobilewikiserver.com/Interpreters.html I'll suggest there was some lifting of concept and quotes by Wired from letter. As of this morning I have no further news, I have heard thru various sources that the issue is not dead yet, So I wait. On 2010-04-16, at 11:09 AM, John M McIntosh wrote: Let me give everyone an update on what is going on with Scratch.app -- === John M. McIntosh john...@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com === smime.p7s Description: S/MIME cryptographic signature ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] We already have the selected projects and students!
Hi folks. First of all, let me apologize for being quite offline the last weeks and for not helping too much. I had some personal stuff to do ;) Fortunately, Janko could take care of it and keep it rolling. Thanks a lot Janko. Here are what all of you want to know: the final results of voting for 5 projects to get this year GSoC stipendiums: 1. Cross-Platform Namespaces (score: 80) by Germán Leiva, mentor James Foster http://gsoc2010.esug.org/projects/namespaces 2. Generate UML diagrams from Smalltalk code for Pharo (score: 77) by Carla Florencia Griggio, mentor Geert Claes http://gsoc2010.esug.org/projects/uml-from-smalltalk 3. Squeakland education project(score: 76) by Ricardo Moran, mentor Randall Caton http://gsoc2010.esug.org/projects/squeakland-education 4. Progress Towards a Cross-Dialect Smalltalk FFI (score: 74) by Dmitry Matveev, mentor Eliot Miranda http://gsoc2010.esug.org/projects/ffi 5. Visualization of profiling information in Pharo and Squeak (score:73) by Mariano Coca, mentor Alexandre Bergel http://gsoc2010.esug.org/projects/profiling-visualization Congratulations to the accepted students! Be aware that the most non enjoyable part of the process has already finished so now it's time to code, hack and have fun! You are the envy of a lot of people, you are being paid to program in something that you really like and enjoy. This is an excellent opportunity so take advantage of it and don't miss it. Please, work hard and deliver something, but never forget to have fun, learn and enjoy. For all the students which were not accepted, don't worry. If your project and proposal is good you will find another opportunity sooner than you expect. For us, this was an excellent opportunity to gather information about really interesting projects and, what's more, to know lots of great students with a passion for Smalltalk. With no doubt, we will keep in touch with all of you and we will eagerly wait your application for next years. Thanks again to all of you for helping us to make the Smalltalk community bigger and better. So stay tuned with us! Cheers Mariano Martinez Peck GSoC admin gsoc-ad...@esug.org http://gsoc2010.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] Some more dev on Polymorph for DrGeo
Hi Hilaire, I gave a try, but I bumped into an error: PastUpMorphadaptToWorld: send a message adaptToWorld: to an instance of EventHandler, which is not defined. I attached a log. I tried on a OSX with a Pharo-1.0-10517-rc4dev10.04.1. If I have a wrong config, let me know. I would like to try. Cheers, Alexandre PharoDebug.log Description: Binary data On 21 Apr 2010, at 12:36, Hilaire Fernandes wrote: Known to work with Pharo 1.0. Someone asked for a more elaborated UI for DrGeo, here are some progresses in this polymorphization of DrGeo. In its latest Monticello package one can grab DrGeo at http://www.squeaksource.com/DrGeoII See enclosed screenshot for a quick view. To start a DrGeo instance, do a DrGeo new in a workspace and enjoy the UI. Beware, style tools does not work in the toolbar. It is also possible to use DrGeo as a service for Etoys when executing a DrGeo sample openInWorld It is also possible to load XML description of DrGeo 1.1 geometric sketch, if one is interested you can grab it at http://svn.gnome.org/viewvc/drgeo/trunk/examples/figures/ and load a sketch with a command: DrGeo newXml: path Beware sketch with embedded Scheme code will not work (just try) Working sketch: mercedes, euler-line, DrGeoII comes with a better interface for scripting with Smalltalk script, empower by the IDE, much nice than the former Scheme one. Elaborated demonstration at http://blog.ofset.org/hilaire/index.php?post/script-drgeo (automatic translation link with Google in a comment, at the end of the article) drgeo-poly.png___ 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] Some more dev on Polymorph for DrGeo
Hum, I see strange info related to Flap, should be gone. Did you install version #185? Hilaire Alexandre Bergel a écrit : Hi Hilaire, I gave a try, but I bumped into an error: PastUpMorphadaptToWorld: send a message adaptToWorld: to an instance of EventHandler, which is not defined. I attached a log. I tried on a OSX with a Pharo-1.0-10517-rc4dev10.04.1. If I have a wrong config, let me know. I would like to try. Cheers, Alexandre On 21 Apr 2010, at 12:36, Hilaire Fernandes wrote: Known to work with Pharo 1.0. Someone asked for a more elaborated UI for DrGeo, here are some progresses in this polymorphization of DrGeo. In its latest Monticello package one can grab DrGeo at http://www.squeaksource.com/DrGeoII See enclosed screenshot for a quick view. To start a DrGeo instance, do a DrGeo new in a workspace and enjoy the UI. Beware, style tools does not work in the toolbar. It is also possible to use DrGeo as a service for Etoys when executing a DrGeo sample openInWorld It is also possible to load XML description of DrGeo 1.1 geometric sketch, if one is interested you can grab it at http://svn.gnome.org/viewvc/drgeo/trunk/examples/figures/ and load a sketch with a command: DrGeo newXml: path Beware sketch with embedded Scheme code will not work (just try) Working sketch: mercedes, euler-line, DrGeoII comes with a better interface for scripting with Smalltalk script, empower by the IDE, much nice than the former Scheme one. Elaborated demonstration at http://blog.ofset.org/hilaire/index.php?post/script-drgeo (automatic translation link with Google in a comment, at the end of the article) drgeo-poly.png___ 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] Some more dev on Polymorph for DrGeo
I did a 'ConfigurationOfDrGeo load ' Alexandre On 21 Apr 2010, at 15:21, Hilaire Fernandes wrote: Hum, I see strange info related to Flap, should be gone. Did you install version #185? Hilaire Alexandre Bergel a écrit : Hi Hilaire, I gave a try, but I bumped into an error: PastUpMorphadaptToWorld: send a message adaptToWorld: to an instance of EventHandler, which is not defined. I attached a log. I tried on a OSX with a Pharo-1.0-10517-rc4dev10.04.1. If I have a wrong config, let me know. I would like to try. Cheers, Alexandre On 21 Apr 2010, at 12:36, Hilaire Fernandes wrote: Known to work with Pharo 1.0. Someone asked for a more elaborated UI for DrGeo, here are some progresses in this polymorphization of DrGeo. In its latest Monticello package one can grab DrGeo at http://www.squeaksource.com/DrGeoII See enclosed screenshot for a quick view. To start a DrGeo instance, do a DrGeo new in a workspace and enjoy the UI. Beware, style tools does not work in the toolbar. It is also possible to use DrGeo as a service for Etoys when executing a DrGeo sample openInWorld It is also possible to load XML description of DrGeo 1.1 geometric sketch, if one is interested you can grab it at http://svn.gnome.org/viewvc/drgeo/trunk/examples/figures/ and load a sketch with a command: DrGeo newXml: path Beware sketch with embedded Scheme code will not work (just try) Working sketch: mercedes, euler-line, DrGeoII comes with a better interface for scripting with Smalltalk script, empower by the IDE, much nice than the former Scheme one. Elaborated demonstration at http://blog.ofset.org/hilaire/index.php?post/script-drgeo (automatic translation link with Google in a comment, at the end of the article) drgeo-poly.png___ 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 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: 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] Some more dev on Polymorph for DrGeo
Alexandre Bergel a écrit : I did a 'ConfigurationOfDrGeo load ' Oh, and this one does not work, bad. Anyway try the latest one #185 from Squeaksource, it is a moving target so there are no ConfigurationOfDrGeo for it Hilaire Alexandre On 21 Apr 2010, at 15:21, Hilaire Fernandes wrote: Hum, I see strange info related to Flap, should be gone. Did you install version #185? Hilaire Alexandre Bergel a écrit : Hi Hilaire, I gave a try, but I bumped into an error: PastUpMorphadaptToWorld: send a message adaptToWorld: to an instance of EventHandler, which is not defined. I attached a log. I tried on a OSX with a Pharo-1.0-10517-rc4dev10.04.1. If I have a wrong config, let me know. I would like to try. Cheers, Alexandre On 21 Apr 2010, at 12:36, Hilaire Fernandes wrote: Known to work with Pharo 1.0. Someone asked for a more elaborated UI for DrGeo, here are some progresses in this polymorphization of DrGeo. In its latest Monticello package one can grab DrGeo at http://www.squeaksource.com/DrGeoII See enclosed screenshot for a quick view. To start a DrGeo instance, do a DrGeo new in a workspace and enjoy the UI. Beware, style tools does not work in the toolbar. It is also possible to use DrGeo as a service for Etoys when executing a DrGeo sample openInWorld It is also possible to load XML description of DrGeo 1.1 geometric sketch, if one is interested you can grab it at http://svn.gnome.org/viewvc/drgeo/trunk/examples/figures/ and load a sketch with a command: DrGeo newXml: path Beware sketch with embedded Scheme code will not work (just try) Working sketch: mercedes, euler-line, DrGeoII comes with a better interface for scripting with Smalltalk script, empower by the IDE, much nice than the former Scheme one. Elaborated demonstration at http://blog.ofset.org/hilaire/index.php?post/script-drgeo (automatic translation link with Google in a comment, at the end of the article) drgeo-poly.png___ 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 already have the selected projects and students!
Thanks you and janko for your energy to carry this adventure in presence of pain in the asses like me :) Stef (I know I'm a pain) On Apr 21, 2010, at 8:27 PM, Mariano Martinez Peck wrote: Hi folks. First of all, let me apologize for being quite offline the last weeks and for not helping too much. I had some personal stuff to do ;) Fortunately, Janko could take care of it and keep it rolling. Thanks a lot Janko. Here are what all of you want to know: the final results of voting for 5 projects to get this year GSoC stipendiums: 1. Cross-Platform Namespaces (score: 80) by Germán Leiva, mentor James Foster http://gsoc2010.esug.org/projects/namespaces 2. Generate UML diagrams from Smalltalk code for Pharo (score: 77) by Carla Florencia Griggio, mentor Geert Claes http://gsoc2010.esug.org/projects/uml-from-smalltalk 3. Squeakland education project(score: 76) by Ricardo Moran, mentor Randall Caton http://gsoc2010.esug.org/projects/squeakland-education 4. Progress Towards a Cross-Dialect Smalltalk FFI (score: 74) by Dmitry Matveev, mentor Eliot Miranda http://gsoc2010.esug.org/projects/ffi 5. Visualization of profiling information in Pharo and Squeak (score:73) by Mariano Coca, mentor Alexandre Bergel http://gsoc2010.esug.org/projects/profiling-visualization Congratulations to the accepted students! Be aware that the most non enjoyable part of the process has already finished so now it's time to code, hack and have fun! You are the envy of a lot of people, you are being paid to program in something that you really like and enjoy. This is an excellent opportunity so take advantage of it and don't miss it. Please, work hard and deliver something, but never forget to have fun, learn and enjoy. For all the students which were not accepted, don't worry. If your project and proposal is good you will find another opportunity sooner than you expect. For us, this was an excellent opportunity to gather information about really interesting projects and, what's more, to know lots of great students with a passion for Smalltalk. With no doubt, we will keep in touch with all of you and we will eagerly wait your application for next years. Thanks again to all of you for helping us to make the Smalltalk community bigger and better. So stay tuned with us! Cheers Mariano Martinez Peck GSoC admin gsoc-ad...@esug.org http://gsoc2010.esug.org ___ 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] Why does datedVersion appear in both SmalltalkImage and SystemVersion?
And because we should continue to shake the trees to get the bad fruits done. Why does datedVersion appear in both SmalltalkImage and SystemVersion? SmalltalkImage delegates to SystemVersion. Why have both? Sean -- View this message in context: http://n4.nabble.com/Why-does-datedVersion-appear-in-both-SmalltalkImage-and-SystemVersion-tp2019137p2019137.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 Because of backwards compatability, and because some people still use/prefer Smalltalk datedVersion over SystemVersion datedVersion. Cheers, Henry ___ 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] Some more dev on Polymorph for DrGeo
It looks good already. It would be great if you could share your tips and tricks for Polymorph in the Pharo book ;) On 21 avr. 2010, at 18:36, Hilaire Fernandes wrote: Known to work with Pharo 1.0. Someone asked for a more elaborated UI for DrGeo, here are some progresses in this polymorphization of DrGeo. In its latest Monticello package one can grab DrGeo at http://www.squeaksource.com/DrGeoII See enclosed screenshot for a quick view. To start a DrGeo instance, do a DrGeo new in a workspace and enjoy the UI. Beware, style tools does not work in the toolbar. It is also possible to use DrGeo as a service for Etoys when executing a DrGeo sample openInWorld It is also possible to load XML description of DrGeo 1.1 geometric sketch, if one is interested you can grab it at http://svn.gnome.org/viewvc/drgeo/trunk/examples/figures/ and load a sketch with a command: DrGeo newXml: path Beware sketch with embedded Scheme code will not work (just try) Working sketch: mercedes, euler-line, DrGeoII comes with a better interface for scripting with Smalltalk script, empower by the IDE, much nice than the former Scheme one. Elaborated demonstration at http://blog.ofset.org/hilaire/index.php?post/script-drgeo (automatic translation link with Google in a comment, at the end of the article) drgeo-poly.png___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Simon ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] HelpSystem (was Documentation Team)
Hi, It's cool to have so many interests in documentation. I deeply think it's a key point to success. As an hobbyist contributor to Pharo documentation :) I wonder whether I should write doc in HelpSystem (which indeed is very cool !) or in the collaborator active book (which is very attractive for me). So a way to get the best of both world may be to generate an HelpSystem book from the collaborator book. Every day, if there has been changes in the collaborative book, it can be packaged automatically as an HelpSystem book / SystemHelp , put on squeaksource, having ConfigurationOfHelpSystem project lastVersion pointing to the last package. Sounds good ? Cheers, Laurent Laffont On Wed, Apr 21, 2010 at 7:56 PM, Torsten Bergmann asta...@gmx.de wrote: To clearify a few things from my side on the discussion on squeak-dev: 1. HelpSystem is working, if ASCII is OK for now we can use it Pharo/Squeak - otherwise I would see it as an early preview. I have clear goals how it should look like in the next iterations. For this more patience is necessary. 2. HelpSystem is independent from where and how the actual information is stored (I think I demonstrated this with the IRC example, the books and the API help). 3. I hope to keep HelpSystem in sync for major Squeak distributions (Squeak, Pharo, Cuis, ...) The last additions from Hannes already broke the code in Pharo. Seems to be a Pharo issue this time http://code.google.com/p/pharo/issues/detail?id=2342 But please dont commit when it is only working in Squeak since my development environment is Pharo. 4. Yes, the content is currently ASCII but the design is prepared to add other types in future releases. A HelpTopic defines an ivar contents - currently referring to a string. I may add another ivar contentType in the future to handle/distinguish additionaly types (HTML, SqueaksRichText, Morphs/BookMorph, ...) 5. HelpSystem should not be limited to Squeak. It should also serve the case that when you write and deploy a commercial app in Squeak you may use it to provide help to your end user/customer 6. There are two types of help I see: A. SystemHelp: Help books/Tutorials/Manuals B. SystemReference: API Help, class comments HelpSystem is supporting both. I already wrote about the differences and details in http://lists.gforge.inria.fr/pipermail/pharo-project/2010-April/024857.html 7. I would really like to see support for HTML viewing in the image (HTMLViewMorph or so) - maybe based on Scamper to get a better viewer (headings, tables, ...) than the current plain text. If people want to contribute they should start right with this task. I know that Laurent already made Scamper loadable in Pharo, dont know about the state in Squeak. There is also another HTML browser with markup and CSS now available open source as MIT (WithStyle), I already mentioned this. http://www.cincomsmalltalk.com/userblogs/rowanb/blogView?showComments=trueprintTitle=Im_back..._but_SWS_isntentry=3364012145 8. I know that we now have discussions on which syntax (Wiki,...) to use for describing the contents. My answer is: it is important but I dont care (yet) since this discussion is useless until we have an HTML viewer (see 7.) and even when there are different syntax styles you can provides builders to transform them into HTML or other contentTypes afterwards. See the class HelpBuilder and subclasses. 9. If you want to write a book for SystemHelp (see 6.A) then the help system provides a class CustomHelp similar to TestCase in SUnit. This class is used to directly map book structures to the class hierarchy. The intention was to be able to create, store and manage these books directly with the usual Smalltalk tools. You can even restructure your book with the RefactoringBrowser. 10. If you want to write API help you (see 6.B) can contribute right now by commenting all the undocumented classes in the standard image. HelpSystem just queries these informations from the usual sources (class comments, ...). I would not change this or make it too complicated since this is what people are used too. I dont see more documented classes by introducing a special syntax (wiki or whatever) people have to learn/know about - so lets clean up documenting the classes first. 11. HelpSystem is able to get contents from external sources (see the IRC example) - but I would prefer that authoring/viewing could be done right from within the image. Even when the result is stored external afterwards. Look at my example books: I can view and change them right from the image and make them available to other images using Metacello/Squeaksource. Accessibility
Re: [Pharo-project] Doc about Coral?
well this is in a bad taste but you can by loading Gofer new squeaksource: 'Coral'; load CoralLoader load I did not try in 1.1 let me know if you succeed Now I'm too busy to push it but I should argh. Syntax is like that: [ Point #ColoredPoint iv: 'color'; iv: 'z'. ] or [Point #ColoredPoint package: #Box. ] or [Point #ColoredPoint iv: 'color z'. ] or [Point #ColoredPoint shared: 'DefaultColor'.] then [Console print: Coral is working, String lf. Console print: Yahoo!] [ Object : #SaBox iv: 'bob' package: 'SandBox' ] SaBoxconvertToFiles: aClass inDirectory: rootDir [ a dummy example that convert a class in a file hierarchy | classDir categoryNames | classDir := (rootDir / aClass asString) mkdir. categoryNames := aClass organization categories collect: [ :aCategory | aCategory asString ]. categoryNames do: [ :aCategoryName | | protocolDir | protocolDir := (classDir / aCategoryName) mkdir. (aClass methodsInCategory: aCategoryName) do: [ :aSelector | (protocolDir / (aSelector asFileName replaceAll: $: with: $_)) asFile contents: (aClass sourceCodeAt: aSelector) ] ]. ^classDir ] [ SaBox new convertToFiles: Object inDirectory: Directory home. Console print: The directory , Directory home path, /Object has been created ] now the parser works and I was in the middle of moving to filessytem and got stuck in pharo. Stef On Apr 21, 2010, at 6:44 PM, Nicolas Petton wrote: Hi, I was wondering if there is some documentation about Coral? I would like to play a bit with it :) Cheers, Nico ___ 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] Talking to Steve Jobs about Scratch.
Good! John in future version it may be good to mention that ESUG supported this VM work for the iphone. STef On Apr 21, 2010, at 8:12 PM, John M McIntosh wrote: Morning, I've posted the letter I had posted to the Apple developer forums and sent to Steve Jobs at http://www.mobilewikiserver.com/Interpreters.html I'll suggest there was some lifting of concept and quotes by Wired from letter. As of this morning I have no further news, I have heard thru various sources that the issue is not dead yet, So I wait. On 2010-04-16, at 11:09 AM, John M McIntosh wrote: Let me give everyone an update on what is going on with Scratch.app -- === 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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Hints and clues for a Pharo newb
On Apr 21, 2010, at 7:11 PM, Lukas Renggli wrote: thisContext is a special object for representing an activation in a stack frame in a stack-based VM. Actually thisContext represents *the current* activation/stack-frame. foo: anObject ^ thisContext at: 1 is the same as foo: anObject ^ anObject There are two kinds of contexts: Method Contexts and Block Contexts. Actually in Pharo images there are only instances of MethodContext. Though you can ask the context if it comes from a block by sending the message #isExecutingBlock. Context creation is optimized in the VM in most Smalltalks, so it's only really created as an object in the environment (reified) when it's specifically needed through thisContext. In Pharo contexts are not reified like that. Stack-frames are actual objects at all times. However, for speed reasons, their creation and garbage-collection is optimized by the VM. Stack frames get automatically recycled if nobody refers to them. Hernan you used VW I see :) In Pharo this is like lukas said, we got this discussion with him for some seaside papers :) There are several applications related with computational reflection (Reflective Programming, Meta-Programming, MOP, etc) which makes use of the current context. Also: exception handling, generators, continuations, co-routines, ... For another fun use of thisContext check this Stack-Overflow question: http://stackoverflow.com/questions/2500483/is-there-a-way-in-a-message-only-language-to-define-a-whiletrue-message-without-r 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] Talking to Steve Jobs about Scratch.
On 2010-04-21, at 1:13 PM, stephane ducasse wrote: Good! John in future version it may be good to mention that ESUG supported this VM work for the iphone. STef Yes, I did conduct a magazine interview today where I ensured I did mentioned that ESUG funding was instrumental in getting the foundations of Scratch (aka Squeak VM) onto the iPhone, otherwise it would never have happened. As everyone should be aware Scratch as an interpreted language is not allowed, but in the future Smalltalk as a language not on the short list is not allowed even if it's hidden from view or ultimately cross compiled into an Objective-C application. -- === John M. McIntosh john...@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com === smime.p7s Description: S/MIME cryptographic signature ___ 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: Talking to Steve Jobs about Scratch.
I've been surprised that I haven't seen any statement from ESUG re: how these policies negatively impact the future prospects for Smalltalk on the iPhone/iPad and the investments they've made in the platform to date that Apple seems willing to wipe out. Wouldn't now be a good time to try to get some visibility on the larger issue? Phil On Apr 21, 2010, at 4:13 PM, stephane ducasse wrote: Good! John in future version it may be good to mention that ESUG supported this VM work for the iphone. STef On Apr 21, 2010, at 8:12 PM, John M McIntosh wrote: Morning, I've posted the letter I had posted to the Apple developer forums and sent to Steve Jobs at http://www.mobilewikiserver.com/Interpreters.html I'll suggest there was some lifting of concept and quotes by Wired from letter. As of this morning I have no further news, I have heard thru various sources that the issue is not dead yet, So I wait. On 2010-04-16, at 11:09 AM, John M McIntosh wrote: Let me give everyone an update on what is going on with Scratch.app -- = = = = = = = 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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Hints and clues for a Pharo newb
On Apr 21, 2010, at 6:09 PM, Peter Hugosson-Miller wrote: Hi all, So it's time for me to stop lurking and do some stuff. However, although I am an experienced Smalltalk programmer (VisualAge Smalltalk continuously since 1995), I am a complete newb when it comes to Pharo and Squeak, it's hard to find my way around, and it's going to take me some time to get up to speed. I'm happy to hear that. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] HelpSystem (was Documentation Team)
Torsten may be you should trun your explanation mail into a book section on book.pharo-project.org because it was cool. http://lists.gforge.inria.fr/pipermail/pharo-project/2010-April/024857.html I think that HelpSystem will be an important piece of Pharo. And I was planning to push it into 1.1 dev :) ASCII is ok for us. Let us be incremental. I like the HelpBrowser openOn: SystemReference :) I think that this is the way to push people to write cool comment. Check the one of URI in 1.1 :) Now how can we turn pragma tagged method comments and Unit tests into entries in your HelpSystem. HelpBuilder of course :) Now could we agree on a nice pragma for tagging methods and another one sunit tests that should be promoted into the SystemReference I believe that we do not have the resources to write separate documentation as VW does. So at least I would have love to have HelpSystem minus minus where we could get book automatically created from the actual contents of the system. Tagging is way more reachable than writing specific documentation. Then I would love to see package level comments... this was this idea behind DrDoc and this is why I should kick my $%^finger to finish RPackage Stef On Apr 21, 2010, at 7:56 PM, Torsten Bergmann wrote: To clearify a few things from my side on the discussion on squeak-dev: 1. HelpSystem is working, if ASCII is OK for now we can use it Pharo/Squeak - otherwise I would see it as an early preview. I have clear goals how it should look like in the next iterations. For this more patience is necessary. 2. HelpSystem is independent from where and how the actual information is stored (I think I demonstrated this with the IRC example, the books and the API help). 3. I hope to keep HelpSystem in sync for major Squeak distributions (Squeak, Pharo, Cuis, ...) The last additions from Hannes already broke the code in Pharo. Seems to be a Pharo issue this time http://code.google.com/p/pharo/issues/detail?id=2342 But please dont commit when it is only working in Squeak since my development environment is Pharo. 4. Yes, the content is currently ASCII but the design is prepared to add other types in future releases. A HelpTopic defines an ivar contents - currently referring to a string. I may add another ivar contentType in the future to handle/distinguish additionaly types (HTML, SqueaksRichText, Morphs/BookMorph, ...) 5. HelpSystem should not be limited to Squeak. It should also serve the case that when you write and deploy a commercial app in Squeak you may use it to provide help to your end user/customer 6. There are two types of help I see: A. SystemHelp: Help books/Tutorials/Manuals B. SystemReference: API Help, class comments HelpSystem is supporting both. I already wrote about the differences and details in http://lists.gforge.inria.fr/pipermail/pharo-project/2010-April/024857.html 7. I would really like to see support for HTML viewing in the image (HTMLViewMorph or so) - maybe based on Scamper to get a better viewer (headings, tables, ...) than the current plain text. If people want to contribute they should start right with this task. I know that Laurent already made Scamper loadable in Pharo, dont know about the state in Squeak. There is also another HTML browser with markup and CSS now available open source as MIT (WithStyle), I already mentioned this. http://www.cincomsmalltalk.com/userblogs/rowanb/blogView?showComments=trueprintTitle=Im_back..._but_SWS_isntentry=3364012145 8. I know that we now have discussions on which syntax (Wiki,...) to use for describing the contents. My answer is: it is important but I dont care (yet) since this discussion is useless until we have an HTML viewer (see 7.) and even when there are different syntax styles you can provides builders to transform them into HTML or other contentTypes afterwards. See the class HelpBuilder and subclasses. 9. If you want to write a book for SystemHelp (see 6.A) then the help system provides a class CustomHelp similar to TestCase in SUnit. This class is used to directly map book structures to the class hierarchy. The intention was to be able to create, store and manage these books directly with the usual Smalltalk tools. You can even restructure your book with the RefactoringBrowser. 10. If you want to write API help you (see 6.B) can contribute right now by commenting all the undocumented classes in the standard image. HelpSystem just queries these informations from the usual sources (class comments, ...). I would not change this or make it too complicated since this is what people are used too. I dont see more
Re: [Pharo-project] [squeak-dev] Re: Talking to Steve Jobs about Scratch.
On Apr 21, 2010, at 10:26 PM, John M McIntosh wrote: On 2010-04-21, at 1:13 PM, stephane ducasse wrote: Good! John in future version it may be good to mention that ESUG supported this VM work for the iphone. STef Yes, I did conduct a magazine interview today where I ensured I did mentioned that ESUG funding was instrumental in getting the foundations of Scratch (aka Squeak VM) onto the iPhone, otherwise it would never have happened. Excellent! As everyone should be aware Scratch as an interpreted language is not allowed, but in the future Smalltalk as a language not on the short list is not allowed even if it's hidden from view or ultimately cross compiled into an Objective-C application. Great! But nothing really new on that front. 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] [squeak-dev] Re: Talking to Steve Jobs about Scratch.
On Apr 21, 2010, at 10:29 PM, Phil (list) wrote: I've been surprised that I haven't seen any statement from ESUG re: how these policies negatively impact the future prospects for Smalltalk on the iPhone/iPad and the investments they've made in the platform to date that Apple seems willing to wipe out. Wouldn't now be a good time to try to get some visibility on the larger issue? We were waiting to get news from the scratch story. And also I'm not a really good politically correct person to write that so any text to start with would help the board to produce a statement going in that direction. 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] HelpSystem (was Documentation Team)
Laurent, i think this is a tension that a number of us feel. should we put documentation in the colab book, or in the system? For me the two are distinct. The book, ultimately, should read as a book. That is there is a logical flow from start to finish and the content is consistent, from start to finish, for a given version of the system. Writing a book appears hard - i have never done it - but i have attempted to copy-edit material that turned out to be as big as a reasonably sized book; i found that near impossible. So whilst the colab book effort is currently in its infancy, i would expect over time it to tend towards being published as a consistent whole. I'm sure anyone involved in SBE/PBE could comment on the real work required to write such a book. As for help in the system, as torsten nicely articulated either Help or Reference, this should really be dynamic. It should change at the unit of which it is changing. so if a new version of a package is loaded, perhaps the Reference docs change. using hyperlink references you should be able to jump around it in an arbitrary order. I don't see a book performing this function. really it must flow consistently from start to finish and the layout of the book is carefully picked by the editors. the only realy hyperlink function is from the TOC, and to any particular index or reference. it is quite distinct from arbitrary jumping at a system doc level. at the moment these two forces I consider are at tension, because there is not enough reference material in the system as we shipped 1.0, and i think the barrier to viewing editing such reference documentation, as a coherent whole, to my satisfaction is harder than using Pier. therefore i find it easier to edit pier even if i have only contributed a few paragraphs. however longer term this will not be the case. We must strive for something akin to Python documentation. as an engineering artifact, it is simply stunning; you can find documentation on anything to do with a given released version. i'm sure this applies to other languages too, i just use python as an example because I particularly like its style towards doc annotation and its completeness. so personally i don't think we should export the pier content into the help system. i see them as quite different, and for both to succeed I think they require a different point of view to writing the content. Torsten - i did not reply to the other thread which stef and I both commented on, have not had the time. For me i am a total pragmatist when it comes toward reference documentation and i am only really interested in reference docs. i fully understand your design and i'm fine with that. I just hope that as a community we can author the reference side, since that is what i feel is most missing. cheers, Mike 2010/4/21 laurent laffont laurent.laff...@gmail.com: Hi, It's cool to have so many interests in documentation. I deeply think it's a key point to success. As an hobbyist contributor to Pharo documentation :) I wonder whether I should write doc in HelpSystem (which indeed is very cool !) or in the collaborator active book (which is very attractive for me). So a way to get the best of both world may be to generate an HelpSystem book from the collaborator book. Every day, if there has been changes in the collaborative book, it can be packaged automatically as an HelpSystem book / SystemHelp , put on squeaksource, having ConfigurationOfHelpSystem project lastVersion pointing to the last package. Sounds good ? Cheers, Laurent Laffont On Wed, Apr 21, 2010 at 7:56 PM, Torsten Bergmann asta...@gmx.de wrote: To clearify a few things from my side on the discussion on squeak-dev: 1. HelpSystem is working, if ASCII is OK for now we can use it Pharo/Squeak - otherwise I would see it as an early preview. I have clear goals how it should look like in the next iterations. For this more patience is necessary. 2. HelpSystem is independent from where and how the actual information is stored (I think I demonstrated this with the IRC example, the books and the API help). 3. I hope to keep HelpSystem in sync for major Squeak distributions (Squeak, Pharo, Cuis, ...) The last additions from Hannes already broke the code in Pharo. Seems to be a Pharo issue this time http://code.google.com/p/pharo/issues/detail?id=2342 But please dont commit when it is only working in Squeak since my development environment is Pharo. 4. Yes, the content is currently ASCII but the design is prepared to add other types in future releases. A HelpTopic defines an ivar contents - currently referring to a string. I may add another ivar contentType in the future to handle/distinguish additionaly types (HTML, SqueaksRichText, Morphs/BookMorph, ...) 5. HelpSystem should not be limited to Squeak. It should also serve the case that when you write and deploy a commercial app
Re: [Pharo-project] [squeak-dev] Re: Talking to Steve Jobs about Scratch.
Phil, last week I asked the smalltalk community (ESUG etc), to stay claim and wait for Apple to think about it based on an email exchange I had with Steve Jobs. At the time I thought it prudent to wait a further decision or statement. Give that Wired publish Alan my thoughts on the matter it's likely now time to consider what to do next. So this is NOT the fault of ESUG not being proactive, they were itching to do something. At the moment I believe they are collecting ideas how to approach the problem in a meaningful manner. Suggestions are welcome. On 2010-04-21, at 1:29 PM, Phil (list) wrote: I've been surprised that I haven't seen any statement from ESUG re: how these policies negatively impact the future prospects for Smalltalk on the iPhone/iPad and the investments they've made in the platform to date that Apple seems willing to wipe out. Wouldn't now be a good time to try to get some visibility on the larger issue? Phil -- === John M. McIntosh john...@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com === smime.p7s Description: S/MIME cryptographic signature ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Fix 2329 - Default MC Directory Setting
Woah This sounds really really cool. Alain is our setting expert and we gotstuck on the how do write a setting chapter. So I'm happy other people like you push this further. Setf In Inbox. http://code.google.com/p/pharo/issues/detail?id=2329. Details: Michael Roberts-2 wrote: I appreciate I hijacked this thread somewhat That's it - I'm pissed and I'm taking my damn thread back ;-) Sean P. DeNigris wrote: http://code.google.com/p/pharo/issues/detail?id=2329 Pharo image: Pharo 1.0 In Monticello Browser, when I click +Repository and select directory, I'd love to be taken right to the directory where I keep my local repositories, instead of having to click to the same place over and over. Okay, now that we're back on track... Stéphane Ducasse wrote: it would be good to be able to either choose to have one local cache on the side of the image or one shared among image - this implies a way to store and set it up = probably a class variable + a setting in 1.1 Steph, I followed your suggestion and implemented it as a class var + settings. Excellent I had to add the capability to have directory-type settings (which was very similar to the existing file type settings, predictably). Summary: * Added ability to System-Settings to have directory-based settings * Added defaultDirectoryName setting to Settings-Monticello * Added feature to Monticello to remember parent directory where user likes to keep local repository directories and start directory-choosing dialogs there. * Tested (by hand) in PharoCore1.1ALPHA Latest update: #11312 Sean -- View this message in context: http://n4.nabble.com/Fix-2329-Default-MC-Directory-Setting-tp2019559p2019559.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] About help
Hi pharo Gofer new squeaksource: 'HelpSystem'; version: 'HelpSystem-Core-tbn.35'; load and enjoy HelpBrowser openOn: SystemReference HelpBrowser openOn: (SystemReference forClass: Integer) HelpBrowser openOn: (SystemReference hierarchyFor: Integer) HelpBrowser openOn: (SystemReference hierarchyWithMethodsFor: Integer) with some tweaks it can be really cool. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] I will restart the integration over the week-end
I was in pharo integration desintoxication phase :) We will have to fix it somehow. but this is cool to see people pushing fixes. 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] HelpSystem (was Documentation Team)
Yes, Python documentation is really impressive, the best I know. May be we can go the other way, from HelpSystem to web. I've tried something like some months ago.ex: http://magaloma.seasidehosting.st/Collections-Streams. So we can have a documentation page like http://docs.python.org/py3k/ with: - collaborator book - web edition of Pharo By Example - HelpSystem books - API reference generated from comments in classes / methods (with the possibility to add comments like jQuery or PHP online docs.) All on one page, starting point to look for documentation, at http://docs.pharo-project.org Cheers, Laurent Laffont On Wed, Apr 21, 2010 at 10:46 PM, Michael Roberts m...@mjr104.co.uk wrote: Laurent, i think this is a tension that a number of us feel. should we put documentation in the colab book, or in the system? For me the two are distinct. The book, ultimately, should read as a book. That is there is a logical flow from start to finish and the content is consistent, from start to finish, for a given version of the system. Writing a book appears hard - i have never done it - but i have attempted to copy-edit material that turned out to be as big as a reasonably sized book; i found that near impossible. So whilst the colab book effort is currently in its infancy, i would expect over time it to tend towards being published as a consistent whole. I'm sure anyone involved in SBE/PBE could comment on the real work required to write such a book. As for help in the system, as torsten nicely articulated either Help or Reference, this should really be dynamic. It should change at the unit of which it is changing. so if a new version of a package is loaded, perhaps the Reference docs change. using hyperlink references you should be able to jump around it in an arbitrary order. I don't see a book performing this function. really it must flow consistently from start to finish and the layout of the book is carefully picked by the editors. the only realy hyperlink function is from the TOC, and to any particular index or reference. it is quite distinct from arbitrary jumping at a system doc level. at the moment these two forces I consider are at tension, because there is not enough reference material in the system as we shipped 1.0, and i think the barrier to viewing editing such reference documentation, as a coherent whole, to my satisfaction is harder than using Pier. therefore i find it easier to edit pier even if i have only contributed a few paragraphs. however longer term this will not be the case. We must strive for something akin to Python documentation. as an engineering artifact, it is simply stunning; you can find documentation on anything to do with a given released version. i'm sure this applies to other languages too, i just use python as an example because I particularly like its style towards doc annotation and its completeness. so personally i don't think we should export the pier content into the help system. i see them as quite different, and for both to succeed I think they require a different point of view to writing the content. Torsten - i did not reply to the other thread which stef and I both commented on, have not had the time. For me i am a total pragmatist when it comes toward reference documentation and i am only really interested in reference docs. i fully understand your design and i'm fine with that. I just hope that as a community we can author the reference side, since that is what i feel is most missing. cheers, Mike 2010/4/21 laurent laffont laurent.laff...@gmail.com: Hi, It's cool to have so many interests in documentation. I deeply think it's a key point to success. As an hobbyist contributor to Pharo documentation :) I wonder whether I should write doc in HelpSystem (which indeed is very cool !) or in the collaborator active book (which is very attractive for me). So a way to get the best of both world may be to generate an HelpSystem book from the collaborator book. Every day, if there has been changes in the collaborative book, it can be packaged automatically as an HelpSystem book / SystemHelp , put on squeaksource, having ConfigurationOfHelpSystem project lastVersion pointing to the last package. Sounds good ? Cheers, Laurent Laffont On Wed, Apr 21, 2010 at 7:56 PM, Torsten Bergmann asta...@gmx.de wrote: To clearify a few things from my side on the discussion on squeak-dev: 1. HelpSystem is working, if ASCII is OK for now we can use it Pharo/Squeak - otherwise I would see it as an early preview. I have clear goals how it should look like in the next iterations. For this more patience is necessary. 2. HelpSystem is independent from where and how the actual information is stored (I think I demonstrated this with the IRC example, the books and the API help). 3. I hope to keep HelpSystem in sync for major Squeak distributions
Re: [Pharo-project] Some more dev on Polymorph for DrGeo
Oh, and this one does not work, bad. Anyway try the latest one #185 from Squeaksource, it is a moving target so there are no ConfigurationOfDrGeo for it Much better! I played a bit, this is really cool. I haven't noticed any non-functional bugs. Cheers, Alexandre Hilaire Alexandre On 21 Apr 2010, at 15:21, Hilaire Fernandes wrote: Hum, I see strange info related to Flap, should be gone. Did you install version #185? Hilaire Alexandre Bergel a écrit : Hi Hilaire, I gave a try, but I bumped into an error: PastUpMorphadaptToWorld: send a message adaptToWorld: to an instance of EventHandler, which is not defined. I attached a log. I tried on a OSX with a Pharo-1.0-10517-rc4dev10.04.1. If I have a wrong config, let me know. I would like to try. Cheers, Alexandre On 21 Apr 2010, at 12:36, Hilaire Fernandes wrote: Known to work with Pharo 1.0. Someone asked for a more elaborated UI for DrGeo, here are some progresses in this polymorphization of DrGeo. In its latest Monticello package one can grab DrGeo at http://www.squeaksource.com/DrGeoII See enclosed screenshot for a quick view. To start a DrGeo instance, do a DrGeo new in a workspace and enjoy the UI. Beware, style tools does not work in the toolbar. It is also possible to use DrGeo as a service for Etoys when executing a DrGeo sample openInWorld It is also possible to load XML description of DrGeo 1.1 geometric sketch, if one is interested you can grab it at http://svn.gnome.org/viewvc/drgeo/trunk/examples/figures/ and load a sketch with a command: DrGeo newXml: path Beware sketch with embedded Scheme code will not work (just try) Working sketch: mercedes, euler-line, DrGeoII comes with a better interface for scripting with Smalltalk script, empower by the IDE, much nice than the former Scheme one. Elaborated demonstration at http://blog.ofset.org/hilaire/index.php?post/script-drgeo (automatic translation link with Google in a comment, at the end of the article) drgeo-poly.png___ 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 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: 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] [squeak-dev] Re: Talking to Steve Jobs about Scratch.
John Stephane, Fair enough and good to know that folks like ESUG will be weighing in. I think you're on the right track re: gathering vocal support from the Scratch community that is constructive rather than bashing Apple, and have mainly been wondering why there wasn't a more concerted push from the Smalltalk and dynamic languages community in general talking about how policies like this would make iPhone OS a non-viable platform for them and push them to invest in alternatives such as Android to the exclusion of iPhone OS, rather than in addition to it. I'm not sure how much additional impact that would have, but the endgame for many tools/languages on iPhone OS doesn't seem to be very far off and I'm not terribly optimistic on how this will be decided. Thanks, Phil On Apr 21, 2010, at 4:48 PM, John M McIntosh wrote: Phil, last week I asked the smalltalk community (ESUG etc), to stay claim and wait for Apple to think about it based on an email exchange I had with Steve Jobs. At the time I thought it prudent to wait a further decision or statement. Give that Wired publish Alan my thoughts on the matter it's likely now time to consider what to do next. So this is NOT the fault of ESUG not being proactive, they were itching to do something. At the moment I believe they are collecting ideas how to approach the problem in a meaningful manner. Suggestions are welcome. On 2010-04-21, at 1:29 PM, Phil (list) wrote: I've been surprised that I haven't seen any statement from ESUG re: how these policies negatively impact the future prospects for Smalltalk on the iPhone/iPad and the investments they've made in the platform to date that Apple seems willing to wipe out. Wouldn't now be a good time to try to get some visibility on the larger issue? Phil -- = = = = = == 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
Re: [Pharo-project] HelpSystem (was Documentation Team)
yes I think that is a nice idea. we would need to see how it fitted in with http://pharo-project.org/documentation as it is currently, and if we load cms-box with all content or something else for dynamically generated stuff like your seaside example (or - static html). cheers, Mike 2010/4/21 laurent laffont laurent.laff...@gmail.com: Yes, Python documentation is really impressive, the best I know. May be we can go the other way, from HelpSystem to web. I've tried something like some months ago.ex: http://magaloma.seasidehosting.st/Collections-Streams. So we can have a documentation page like http://docs.python.org/py3k/ with: - collaborator book - web edition of Pharo By Example - HelpSystem books - API reference generated from comments in classes / methods (with the possibility to add comments like jQuery or PHP online docs.) All on one page, starting point to look for documentation, at http://docs.pharo-project.org Cheers, Laurent Laffont On Wed, Apr 21, 2010 at 10:46 PM, Michael Roberts m...@mjr104.co.uk wrote: Laurent, i think this is a tension that a number of us feel. should we put documentation in the colab book, or in the system? For me the two are distinct. The book, ultimately, should read as a book. That is there is a logical flow from start to finish and the content is consistent, from start to finish, for a given version of the system. Writing a book appears hard - i have never done it - but i have attempted to copy-edit material that turned out to be as big as a reasonably sized book; i found that near impossible. So whilst the colab book effort is currently in its infancy, i would expect over time it to tend towards being published as a consistent whole. I'm sure anyone involved in SBE/PBE could comment on the real work required to write such a book. As for help in the system, as torsten nicely articulated either Help or Reference, this should really be dynamic. It should change at the unit of which it is changing. so if a new version of a package is loaded, perhaps the Reference docs change. using hyperlink references you should be able to jump around it in an arbitrary order. I don't see a book performing this function. really it must flow consistently from start to finish and the layout of the book is carefully picked by the editors. the only realy hyperlink function is from the TOC, and to any particular index or reference. it is quite distinct from arbitrary jumping at a system doc level. at the moment these two forces I consider are at tension, because there is not enough reference material in the system as we shipped 1.0, and i think the barrier to viewing editing such reference documentation, as a coherent whole, to my satisfaction is harder than using Pier. therefore i find it easier to edit pier even if i have only contributed a few paragraphs. however longer term this will not be the case. We must strive for something akin to Python documentation. as an engineering artifact, it is simply stunning; you can find documentation on anything to do with a given released version. i'm sure this applies to other languages too, i just use python as an example because I particularly like its style towards doc annotation and its completeness. so personally i don't think we should export the pier content into the help system. i see them as quite different, and for both to succeed I think they require a different point of view to writing the content. Torsten - i did not reply to the other thread which stef and I both commented on, have not had the time. For me i am a total pragmatist when it comes toward reference documentation and i am only really interested in reference docs. i fully understand your design and i'm fine with that. I just hope that as a community we can author the reference side, since that is what i feel is most missing. cheers, Mike 2010/4/21 laurent laffont laurent.laff...@gmail.com: Hi, It's cool to have so many interests in documentation. I deeply think it's a key point to success. As an hobbyist contributor to Pharo documentation :) I wonder whether I should write doc in HelpSystem (which indeed is very cool !) or in the collaborator active book (which is very attractive for me). So a way to get the best of both world may be to generate an HelpSystem book from the collaborator book. Every day, if there has been changes in the collaborative book, it can be packaged automatically as an HelpSystem book / SystemHelp , put on squeaksource, having ConfigurationOfHelpSystem project lastVersion pointing to the last package. Sounds good ? Cheers, Laurent Laffont On Wed, Apr 21, 2010 at 7:56 PM, Torsten Bergmann asta...@gmx.de wrote: To clearify a few things from my side on the discussion on squeak-dev: 1. HelpSystem is working, if ASCII is OK for now we can use it Pharo/Squeak - otherwise I would see it as an early preview. I have clear
Re: [Pharo-project] Hints and clues for a Pharo newb
2010/4/21 Lukas Renggli reng...@gmail.com: thisContext is a special object for representing an activation in a stack frame in a stack-based VM. Actually thisContext represents *the current* activation/stack-frame. foo: anObject ^ thisContext at: 1 is the same as foo: anObject ^ anObject Of course, this refers to the current in common language usage. There are two kinds of contexts: Method Contexts and Block Contexts. Actually in Pharo images there are only instances of MethodContext. Though you can ask the context if it comes from a block by sending the message #isExecutingBlock. Actually in Pharo there is a BlockContext class, which is not instantiated anymore after the introduction of the closure compiler? In other Smalltalks aBlockContext is the resulting context of a block activation during its evaluation and is activated by sending #value,.this fills thisContext with the execution information inside the block. In Squeak (or the old compiler) block contexts were created using #blockCopy:, now I see #closureNumCopied:numArgs:. Does this means BlockContext could be completely removed and replaced with MethodContext semantics? I've removed the BlockContext class and used Pharo a little bit with no problems, maybe some Decompiler issues in the Debugger... Now, test yourself before evaluating :) what should be the result of this expression? [: arg | arg perform: #isExecutingBlock ] value: thisContext Can somebody justify the result? Context creation is optimized in the VM in most Smalltalks, so it's only really created as an object in the environment (reified) when it's specifically needed through thisContext. In Pharo contexts are not reified like that. Stack-frames are actual objects at all times. However, for speed reasons, their creation and garbage-collection is optimized by the VM. Stack frames get automatically recycled if nobody refers to them. I think is what I said :) There are several applications related with computational reflection (Reflective Programming, Meta-Programming, MOP, etc) which makes use of the current context. Also: exception handling, generators, continuations, co-routines, ... For another fun use of thisContext check this Stack-Overflow question: http://stackoverflow.com/questions/2500483/is-there-a-way-in-a-message-only-language-to-define-a-whiletrue-message-without-r 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] Fix 2329 - Default MC Directory Setting
Stéphane Ducasse wrote: Alain is our setting expert and we gotstuck on the how do write a setting chapter. So I'm happy other people like you push this further. My experience as a settings beginner. It was actually really easy because: * '*setting*' is used everywhere, so I did a 'class find' and immediately found the settings categories * there are a lot of examples all together in the settings categories I think the hardest thing was the xxxOn: aBuilder pragma concept in general (same goes for the new world menu) - it's not immediately obvious (via my typical highlight and browse it method) where to look for the class that scooped all the setting methods up and built the browser. I remember my initial thought was now what would I look under to find the thing that generates and passes in aBuilder? Also, I think this model of keeping settings in separate packages is definitely easier from a learning perspective because you have all working examples in the same place. When I implemented my first worldMenu pragma method, it took a while to figure out how to generate a list of all methods currently using worldMenu so I could see how it was done. I was looking for a SystemNavigator allMethodsUsingPragma: aSymbol, or something like that. With that funtionality, I guess it really wouldn't matter where they were located - or am I missing an easy way to find these methods? Sean -- View this message in context: http://n4.nabble.com/Fix-2329-Default-MC-Directory-Setting-tp2019559p2019958.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] [Question] ToolBuilder in Squeak 4.1 and Pharo 1.0 compatible?
On 4/21/2010 4:32 AM, Hannes Hirzel wrote: A question: Art the ToolBuilder in Squeak 4.1 and Pharo 1.0 the same? Or if there is a difference what is the impact of it? Or put the question in another way. If I code an UI using the ToolBuilder in Squeak 4.1 will it run in Pharo? They are mostly the same but not identical. If there is interest in the Pharo community we should merge the versions upstream in http://www.squeaksource.com/ToolBuilder.html (contact me if you're interested). Cheers, - Andreas ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [Vm-dev] CMake for Windows?
Ping! I know everyone is busy, but could someone test these CMake files? I can't install a VM to build unix Squeak right now, but I'll do it in the future. I just want to know if it's still possible to create unix squeak with these files :) On Sat, Apr 17, 2010 at 1:23 AM, Geoffroy Couprie geo.coup...@gmail.com wrote: Hello, You'll find my work on the CMake files at http://eleves.ec-lille.fr/~couprieg/divers/patches.zip I put a CMakeLists.txt file just under the platforms/ directory, along with the cmake/ directory. These files are based on the unix ones. I modified them to change the source directory depending on the platform. I also modified the configure file accordingly, but i commented the code using subversion for my convenience during development (feel free to change it back). These CMake files are not perfect, it's just the beginning. First, I want to make sure that the unix port still builds with my file, and then, I'll go on with the config.cmake and build.cmake files for the plugins, and I'll clean CMakeLists.txt a bit. Feel free to comment, but note that I'm beginning with CMake, and that I don't write bash code very often. And please, try it with the unix port. I don't want to break everything :) Anyway, it works for me here (I can build a VM on Windows with the File, Security, LargeIntegers and MiscPrimitive plugins using MSYS+MinGW). Best regards, Geoffroy ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Fix 2329 - Default MC Directory Setting
On 22.04.2010 04:45, Sean P. DeNigris wrote: I was looking for a SystemNavigator allMethodsUsingPragma: aSymbol, or something like that. With that funtionality, I guess it really wouldn't matter where they were located - or am I missing an easy way to find these methods? Sean You could try PragmaCollector, which is quite neat. (PragmaCollector filter: [:pragma | pragma keyword = #worldMenu]) reset The problem with an allMethodsUsingPragmaWithKeyword: method, would be that people might think it was ok to use without caution, which it's not :) [100 timesRepeat: [PragmaCollector allSystemPragmas]] timeToRun 6245 So when using pragmas, a good idea is to either use a PragmaCollector like a cache (dynamically updated one, that is), or limit the search scope of the pragmas you accept, usually to a class. PragmaCollector does not exist in Squeak though, it's one of the pieces I think they'd find useful too. In fact, currently they have one implemented in methods on Preferences, in the dynamic preferences category. Class-scoped pragmas is what is used in VW for menu building. 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] [Vm-dev] CMake for Windows?
On linux, configure fails: -- Configuring done CMake Error in CMakeLists.txt: Cannot find source file aio.c. Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx aio.c is in .unix/vm/aio.c Cheers, Laurent Laffont On Thu, Apr 22, 2010 at 7:23 AM, Geoffroy Couprie geo.coup...@gmail.comwrote: Ping! I know everyone is busy, but could someone test these CMake files? I can't install a VM to build unix Squeak right now, but I'll do it in the future. I just want to know if it's still possible to create unix squeak with these files :) On Sat, Apr 17, 2010 at 1:23 AM, Geoffroy Couprie geo.coup...@gmail.com wrote: Hello, You'll find my work on the CMake files at http://eleves.ec-lille.fr/~couprieg/divers/patches.zip I put a CMakeLists.txt file just under the platforms/ directory, along with the cmake/ directory. These files are based on the unix ones. I modified them to change the source directory depending on the platform. I also modified the configure file accordingly, but i commented the code using subversion for my convenience during development (feel free to change it back). These CMake files are not perfect, it's just the beginning. First, I want to make sure that the unix port still builds with my file, and then, I'll go on with the config.cmake and build.cmake files for the plugins, and I'll clean CMakeLists.txt a bit. Feel free to comment, but note that I'm beginning with CMake, and that I don't write bash code very often. And please, try it with the unix port. I don't want to break everything :) Anyway, it works for me here (I can build a VM on Windows with the File, Security, LargeIntegers and MiscPrimitive plugins using MSYS+MinGW). Best regards, Geoffroy ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
