- Pharo-dev - lists.pharo.org

Re: [Pharo-project] TestIndenting fails with Exupery (was: [BetaTesting] [ANN] Pharo1.0-10507-rc2dev10.01.2)

by laurent laffont

> I will have less time from today as I'm starting a new job. >> >> > Good luck! In smalltalk ? > No :( , PHP + Java Laurent

Jan. 25, 2010

[Pharo-project] CFPaper: 4th Workshop on Dynamic Languages and Applications

by Alexandre Bergel

4th Workshop on Dynamic Languages and Applications (DYLA 2010) (collocated with TOOLS) categories: programming languages, software engineering, computer science When: Jun 28, 2010 - Jun 28, 2010 Where: Malaga, Spain Submission Deadline: Mar 31, 2010 Notification Due: May 14, 2010 Final Version Due: May 31, 2010 link: http://scg.unibe.ch/wiki/events/dyla2010 Call For Papers The DYLA Workshop series focuses on the revival of dynamic languages. These days, dynamic languages (like Ruby, Python, JavaScript, Lua, etcâ¦) are getting ever more popular. This is a call to arms for academia! We need to explore the future of dynamic languages through its human aspects and technical issues. We also ought to look back and pick up solutions from existing dynamic languages (such as Scheme, Smalltalk, or Self) to be rediscovered and spread around. Goal and Topics The goal of this workshop is to act as a forum where we can discuss dynamic languages and their applications. Topics of interest include any topic relevant in applying and/or supporting dynamic languages: Ruby, Python, Groovy, JavaScript, Lua, Clojure, Lisp, Scheme, Smalltalk, Self, ABCL, Prolog, and many moreâ¦ Human aspects of dynamic languages, such as â empirical studies about the application of dynamic languages â best practices and patterns specific to dynamic languages â program correctness through unit testing (as opposed to types) â improved or novel IDE support for dynamic languages â use of dynamic features by library & framework developers â scripting of static application with dynamic languages â reverse engineering and analysis of dynamic applications Technical aspects of dynamic languages, such as â what features make a language a dynamic one? â agents, actors, active object, distribution, concurrency and mobility â delegation, prototypes, mix-ins, traits â first-class closures, continuations, environments â reflection and meta-programming â automated reasoning about programs written in dynamic languages â (concurrent/distributed/mobile/aspect) virtual machines â optimization of dynamic languages â multi-paradigm & static/dynamic-marriages â type systems for dynamic languages â (dynamic) aspects for dynamic languages â higher-order objects & messages â â¦other exotic dynamic features Submissions The workshop will have a demo-oriented style. The idea is to allow participants to demonstrate new and interesting features and discuss what they feel is relevant for the dynamic language community. Participants need to submit a 2â4 page position paper of their work in ACM, sig-alternate.cls format. At the workshop, participants will be asked to give 10-minute âlightning demosâ of their contributions. Submission page is https://www.easychair.org/login.cgi?conf=dyla10 Organizers â Alexandre Bergel, Univ of Chile, â Carl Friedrich Bolz, Heinrich-Heine-Univ, DÃ¼sseldorf, Germany â Simon Denier, INRIA Lille, France â Michael Haupt, HPI Potsdam, Germany â Adrian Kuhn, Univ of Bern, Switzerland Program Committee â Tom Dinkelaker, Technische Univ Darmstadt, Germany â Johan Fabry, Univ of Chile â Matthew Flatt, Univ of Utah, USA â Stephan Herrmann, TU Berlin, Germany â Abram Hindle, Univ of Waterloo, Canada â Kasper Lund, Google, Denmark. â Michael Perscheid, HPI Potsdam, Germany â Rodolfo Toledo, Univ of Chile â Niko Schwarz, Univ of Bern, Switzerland â Peter Sommerlad, HSR Rapperswil, Switzerland â Alessandro Warth, Viewpoints Research Institute, USA â Vadim Zaytsev, Univ of Koblenz, Germany For further information, please visit our website or follow us on twitter â http://bit.ly/dyla2010 â http://twitter.com/dyla2010 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 25, 2010

Re: [Pharo-project] RBSpelling errors when class has Pool Dictionary - Re: [BetaTesting] [ANN] Pharo1.0-10507-rc2dev10.01.2

by Lukas Renggli

>> They are all not flagged on my machine. Neither with the internal nor >> with the mac spelling. >> > Still flagged here. Seem to be extra ' characters in the check strings. > See Â http://www.flickr.com/photos/8185994@N03/4303501422/sizes/o/ search > strings screen print on Flickr The words you show are simply not in the dictionary: - These words I don't know, but I am not a native speaker: ftmch drepehs - The implementation excepts to have natural language in comments, not code. Thus this is not split: goodVariable - I don't know about apostrophes at the end of the word. Should they be removed? methods'' don't' RB' IT' OK' Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Jan. 25, 2010

Re: [Pharo-project] [newbee] How do I save the contents of aWorkspace?

by Gary Chambers

The base UIManager code has no accessors for file saving, though Polymorph does support such a dialog... Try UITheme builder fileSave: "Your dialog title here' Regards, Gary ----- Original Message ----- From: "George Herolyants" <george.herolyants(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Monday, January 25, 2010 11:07 AM Subject: Re: [Pharo-project] [newbee] How do I save the contents of aWorkspace? Bill, Mariano thanks for the feedback! 2010/1/21 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Thanks for doing this! How did you modify the menu? I have *no* clue how > to do that. There is a method addModelItemsToWindowMenu:, which do the job. > Two comments, the first horribly pedantic. The prompt for the file name > reads "Enter file name to save the workspace to" - we have no shortage of > dangling prepositions. "Ener file name" would be preferable. I agree. > More substantively, it does not prompt for a directory. I agree that the > image directory is the most likely default, but Pinesoft probably > has > given us a suitable file dialog, and if not, we should identify the > omission. There is such a dialog. FileDialogWindow. I use it when I ask user for file name to open. But I didn't find any way to force this dialog to ask for the new file name. I may be wrong, but it only allows user to choose from existing file names. Some comments from more experienced people would be helpful though. George _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 25, 2010

Re: [Pharo-project] [newbee] How do I save the contents of a Workspace?

by Schwab,Wilhelm K

George, Thanks for the tip on the menus. If FileDialogWindow is indeed missing a way to create a new name, I suspect Gary will eventually add that ability because it is important for end users wanting to save files. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of George Herolyants Sent: Monday, January 25, 2010 6:07 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [newbee] How do I save the contents of a Workspace? Bill, Mariano thanks for the feedback! 2010/1/21 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Thanks for doing this! Â How did you modify the menu? Â I have *no* clue how to do that. There is a method addModelItemsToWindowMenu:, which do the job. > Two comments, the first horribly pedantic. Â The prompt for the file name reads "Enter file name to save the workspace to" - we have no shortage of dangling prepositions. Â "Ener file name" would be preferable. I agree. > More substantively, it does not prompt for a directory. Â I agree that the image directory is the most likely default, but Pinesoft probably > has given us a suitable file dialog, and if not, we should identify the omission. There is such a dialog. FileDialogWindow. I use it when I ask user for file name to open. But I didn't find any way to force this dialog to ask for the new file name. I may be wrong, but it only allows user to choose from existing file names. Some comments from more experienced people would be helpful though. George _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 25, 2010

Re: [Pharo-project] [newbee] How do I save the contents of a Workspace?

by George Herolyants

Bill, Mariano thanks for the feedback! 2010/1/21 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Thanks for doing this! Â How did you modify the menu? Â I have *no* clue how to do that. There is a method addModelItemsToWindowMenu:, which do the job. > Two comments, the first horribly pedantic. Â The prompt for the file name reads "Enter file name to save the workspace to" - we have no shortage of dangling prepositions. Â "Ener file name" would be preferable. I agree. > More substantively, it does not prompt for a directory. Â I agree that the image directory is the most likely default, but Pinesoft probably > has given us a suitable file dialog, and if not, we should identify the omission. There is such a dialog. FileDialogWindow. I use it when I ask user for file name to open. But I didn't find any way to force this dialog to ask for the new file name. I may be wrong, but it only allows user to choose from existing file names. Some comments from more experienced people would be helpful though. George

Jan. 25, 2010

Re: [Pharo-project] Monticello diff between chosen revisions isbroken

by Gary Chambers

The "Diff" button on the Monticello repository browser does what its balloon help says... 'Create an equivalent version based on an earlier release'. This is a diff version. I never use them as they can be confusing :-) If you want to compare two existing versions you should: 1. Open Monticello Browser 2. Select a repo 3. click open 4. Select a revision, not the latest one 5. Click HISTORY 6. chose an ancestor from the list Regards, Gary ----- Original Message ----- From: Mariano Martinez Peck To: Pharo-project(a)lists.gforge.inria.fr Cc: Lukas Renggli Sent: Sunday, January 24, 2010 12:59 PM Subject: Re: [Pharo-project] Monticello diff between chosen revisions isbroken On Sat, Jan 23, 2010 at 9:51 PM, Stefan Marr <pharo(a)stefan-marr.de> wrote: Hi: In the current dev image (10508), Monticello is broken with respect to showing the differences of between chosen revisions. However, that seems to be broken already in 10496. (and maybe earlier) To reproduce: 1. Open Monticello Browser 2. Select a repo 3. click open 4. Select a revision, not the latest one 5. Click diff 6. chose an ancestor from the list Now you got a window 'Version: ...5' Saying (Diff against ...2) Here I would expect the changes button to open a window showing the changes between the chosen revisions, but it always diffs against the latest version. Yes, I could reproduce the problem. Can you open a ticket ? Maybe Lukas Monticello guru can help us ? hahaha Cheers Mariano Best Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 3956 Fax: +32 2 629 3525 _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ------------------------------------------------------------------------------ _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 25, 2010

Re: [Pharo-project] RBSpelling errors when class has Pool Dictionary - Re: [BetaTesting] [ANN] Pharo1.0-10507-rc2dev10.01.2

by Stan Shepherd

Lukas Renggli wrote: > > 'rong' is in the dictionary as a correct word thus it is correct. ... > OK, when I use a different misspelling those tests pass. >> 'IT' 'OK and 'don't' are all flagged - don't is not flagged. Is this your >> preferred behaviour? > > They are all not flagged on my machine. Neither with the internal nor > with the mac spelling. > Still flagged here. Seem to be extra ' characters in the check strings. See http://www.flickr.com/photos/8185994@N03/4303501422/sizes/o/ search strings screen print on Flickr ...Stan -- View this message in context: http://n2.nabble.com/BetaTesting-ANN-Pharo1-0-10507-rc2dev10-01-2-tp4440307… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 25, 2010

Re: [Pharo-project] about imageSegments

by Adrian Lienhard

On Jan 25, 2010, at 10:24 , Igor Stasenko wrote: > 2010/1/25 Adrian Lienhard <adi(a)netstyle.ch>: >> On Jan 25, 2010, at 09:57 , Mariano Martinez Peck wrote: >> >>> On Mon, Jan 25, 2010 at 9:02 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >>> >>>> Hi Stef >>>> >>>> We can move the few classes related to image segments into a separate >>>> package in SqueakSource. The system (ideally) does not depend on them so it >>>> should not be too hard to package them separately. >>>> >>>> >>> There are several things I would like to say: >>> >>> - The ImageSegment code really suc.. and it is very difficult to understand, >>> maintain and test. It is full of etoys, morphic, project and other stuff. >>> - There are a lot of methods that do a lot of black magic >>> - The code is VERY fragile and may be broke any time (if it is not already >>> broken) >>> >>> However, >>> >>> - Some people use it >>> - It is fast >> >> I think image segments is a very nice idea and it works very well if you know how to use them. The core, which is used for basic store/load, is not that complicated. But image segments have been hacked in ugly ways for project persistency. Hence, there is a lot of complexity that is not needed. >> > > Just one question: Why it is an ImageSegments which been hacked, but > not a Project themselves? Probably because it was easier that way ;). As far as I understand a lot of code deals with storing presenters (Etoys) and projects/morphs in clever ways. This is additional behavior that you don't need (anymore). I think if we remove this, we get a very small class that is much simpler to understand and use. Adrian

Jan. 25, 2010

Re: [Pharo-project] about imageSegments

by Igor Stasenko

2010/1/25 Adrian Lienhard <adi(a)netstyle.ch>: > On Jan 25, 2010, at 09:57 , Mariano Martinez Peck wrote: > >> On Mon, Jan 25, 2010 at 9:02 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >> >>> Hi Stef >>> >>> We can move the few classes related to image segments into a separate >>> package in SqueakSource. The system (ideally) does not depend on them so it >>> should not be too hard to package them separately. >>> >>> >> There are several things I would like to say: >> >> - The ImageSegment code really suc.. and it is very difficult to understand, >> maintain and test. It is full of etoys, morphic, project and other stuff. >> - There are a lot of methods that do a lot of black magic >> - The code is VERY fragile and may be broke any time (if it is not already >> broken) >> >> However, >> >> - Some people use it >> - It is fast > > I think image segments is a very nice idea and it works very well if you know how to use them. The core, which is used for basic store/load, is not that complicated. But image segments have been hacked in ugly ways for project persistency. Hence, there is a lot of complexity that is not needed. > Just one question: Why it is an ImageSegments which been hacked, but not a Project themselves? >> If you ask if we should remove it form core, I would say: >> >> - It won't very VERY easy to completely remove them. There are some places >> where ImageSegment are inside the code and won't be easy to remove. Or at >> least, leave the code with Smalltalk at: #ImageSegment ifPresent: [blah..] >> Look for example, >> Behavior >> allInstancesEverywhereDo: >> ClassDescription >> updateInstancesFrom: >> All those doGently and isInMemory > > I don't think it is very hard. Methods such as allInstancesEverywhereDo: can be deleted. They implement iterating over object in segments that may be stored on disk. This is too much magic in my eyes. I would only keep the core to do basic segment store/load. > >> So...remove then would be easy, but put them in a separate package, still >> working and without Smalltalk at: ifPresent Â I think it would be difficult. >> >> I have already clean, fix and test it as much as possible. I will let them >> in Pharo and as Martin said, getting it better when someone has time and is >> willing to do it. > > When I find some time I'll try to continue from your work and extract them into a separate package. > >> Another problem is that if we remove ImageSegment to an external package, >> will be soon outdated and nobody will maintain it. > > I believe it may be even the other way round. If image segments (or any other package) is external to the image, it is easier to commit changes. Even though image segments have been around for 10 years inside Squeak they have not been maintained, so it can only get better ;) > > Cheers, > Adrian > >> >> Cheers >> >> Mariano >> >> >> Adrian >>> >>> On Jan 22, 2010, at 21:35 , StÃ©phane Ducasse wrote: >>> >>>> hi guys >>>> >>>> the more I read about imageSegments the more I would like to remove them >>> (or to package them >>>> carefully - not sure that this is possible) and may be Â add a new class >>> to >>>> just have one simple way of invoking the save (but not swapping back in) >>>> >>>> I think that mariano diving into them is a great phd exercise but on the >>> long run >>>> I see it as a brittle mechanism. >>>> >>>> what do you think? >>>> >>>> Stef >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Jan. 25, 2010