August 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Problem with Author

by Mariano Martinez Peck

2009/8/17 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com> > El lun, 17-08-2009 a las 18:13 -0300, Mariano Martinez Peck escribiÃ³: > > > > > > 2009/8/17 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com> > > El lun, 17-08-2009 a las 16:42 -0300, Mariano Martinez Peck > > escribiÃ³: > > > Hi folks: I think I found a little bug with the Author > > refactor. To > > > reproduce: > > > > > > 1) Open Monticello browser > > > 2) select a package you modified something, select a > > repository and > > > press save > > > 3) The popup asking you the full name and surename is > > opened. The > > > thing is that if you press cancel, it closes the popup but > > another one > > > is opened :( yo have no other choice that put "ok" > > > > > > > Yes, this is how the original prompt for initials worked > > before the > > rewrite, I didn't modify it. > > The thinkg is, it keeps asking until you enter something. > > > > If you could press cancel, when you do other modification, it > > will > > prompt again, so I prefer to keep the old behavior of a > > continuous > > asking for full name. > > > > But this could be changed, of course. What should be the > > behavior? > > > > The behavior must be just cancel. Close the popup and do nothing. Not > > to open the popup again. > > > > > > But this maybe can brake other parts, as the generation of signature for > methods. Supposing that the Author class let the cancel proceed. This > will necessarily to store nil or '' in the fullName inst var of Author. > the calling code (in this case, the evaluate part of the browser or the > debug windows where you modified some code) won't know that the author > hasn't stored the name correctly, so it will procedd as if were. Then > when saving the method/exporting to mc/generating the signature of the > method maybe will go on the assumption that there is a name stored. > Well you get the idea. Maybe I am exaggerating but will be necessary to > review the code using Author to see what will happen if a '' or nil is > stored there. Ups.... You are right. Sorry, I was thinking funtioncallity, not programatically. I would love that when I press "cancel", the generation of signature and all the next code isn't called. > > Of course also can be true that nothing wrong happens (at least with a > nil stored the next time it will prompt again for a full name). > > What say the community? :) > > > > > > > > > Can anyone reproduce this ? If so, I'll open a bug ticket. > > > > > > Best, > > > > > > Mariano > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > > > > Miguel CobÃ¡ > > http://miguel.leugim.com.mx > > > > > > > > _______________________________________________ > > 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 > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 17, 2009

[Pharo-project] [ANN] prebuild PharoCore-1.0-10414-BETA

by Marcus Denker

Hi, To save time... https://gforge.inria.fr/frs/download.php/22770/PharoCore-1.0-10414-BETA.zip Marcus -- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile

Aug. 17, 2009

[Pharo-project] Getting Javascript in Moose and/or Pharo

by Alexandre Bergel

Dear List Making Pharo interacting with Javascript has been the cup of tea of the Seaside community. I am wondering whether there has been an attempt to produce a parser for Javascript within Pharo. We are interested in getting Javascript models within Moose. For now, it is likely what we will use the parser of Mozilla to produce MSE files. Cheers, Alexandre NB: Sorry for the cross-posting -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 17, 2009

Re: [Pharo-project] Problem with Author

by Miguel Enrique CobÃ¡ Martinez

El lun, 17-08-2009 a las 18:13 -0300, Mariano Martinez Peck escribiÃ³: > > > 2009/8/17 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com> > El lun, 17-08-2009 a las 16:42 -0300, Mariano Martinez Peck > escribiÃ³: > > Hi folks: I think I found a little bug with the Author > refactor. To > > reproduce: > > > > 1) Open Monticello browser > > 2) select a package you modified something, select a > repository and > > press save > > 3) The popup asking you the full name and surename is > opened. The > > thing is that if you press cancel, it closes the popup but > another one > > is opened :( yo have no other choice that put "ok" > > > > Yes, this is how the original prompt for initials worked > before the > rewrite, I didn't modify it. > The thinkg is, it keeps asking until you enter something. > > If you could press cancel, when you do other modification, it > will > prompt again, so I prefer to keep the old behavior of a > continuous > asking for full name. > > But this could be changed, of course. What should be the > behavior? > > The behavior must be just cancel. Close the popup and do nothing. Not > to open the popup again. > > But this maybe can brake other parts, as the generation of signature for methods. Supposing that the Author class let the cancel proceed. This will necessarily to store nil or '' in the fullName inst var of Author. the calling code (in this case, the evaluate part of the browser or the debug windows where you modified some code) won't know that the author hasn't stored the name correctly, so it will procedd as if were. Then when saving the method/exporting to mc/generating the signature of the method maybe will go on the assumption that there is a name stored. Well you get the idea. Maybe I am exaggerating but will be necessary to review the code using Author to see what will happen if a '' or nil is stored there. Of course also can be true that nothing wrong happens (at least with a nil stored the next time it will prompt again for a full name). What say the community? :) > > > > Can anyone reproduce this ? If so, I'll open a bug ticket. > > > > Best, > > > > Mariano > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- > > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > > _______________________________________________ > 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 -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Aug. 17, 2009

Re: [Pharo-project] Problem with Author

by Mariano Martinez Peck

On Mon, Aug 17, 2009 at 6:09 PM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > > I suppose you refer to the last time you enter your name on *other* > > image as if it is the same image, it won't ask for the full name as > > already have it. > > Exact. > > > I think that someone (maybe you) asked for the capability of storing > > the > > full name on the computer disk and if found it will pre-fill the > > prompt. > > That was an idea yes. Would be nice > > > > I can add this to the author code, but just need to ask if: > > - is there a convention for storing squeak/pharo settings e.g. in > > linux > > could be a .squeak/ or .pharo/ folder on the $HOME of the user. In > > windows I suppose that in my documents but I really don't use it so I > > don't know. > > I would not rely on this. I usually have my images a bit everywhere. > and move frequently them around. > > > - is there a convention for storing this files besides the > > image/changes/sources files. This is as the current pharo/squeak > > works, > > I think. > > next to the image will make me happy. But if you put that file in next to the image and you then have another image is probable it to be in a different directory. > > > > - the preference browser has the capability of storing the preferences > > in a file. Maybe this could be reused and include the full name and > > try > > to read from there on first full name prompt. > > Could be yes > > > Will be useful to other users to have this, supposing the they change > > image often, or the hassle of writing by hand once for image it is > > negligible? > > It will be useful for me yes > > Alexandre > > > > > >> Like this, I just have to press 'Ok'. > >> > >> Alexandre > >> > > -- > > Miguel CobÃ¡ > > http://miguel.leugim.com.mx > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 17, 2009

[Pharo-project] Native Windows

by Eagle Offshore

I spent the weekend trying to get Ffenestri working in Pharo. It was astonishingly painful, not the least of which because they are stored as half a dozen monticello archives and the MC tool merge tool requires you to address each conflict individually and the main change is that at lot of morphic methods now have comments and _ has been replaced with :=. There must be a better way. Also, the files have a lot of patches to Delay and Process and really scary stuff like that and I was under the impression that those things had been reworked since and I didn't want to introduce any sort of regression so I didn't load them and focused on just making the plugin interface work and patching the event delivery code to deliver window events to the host windows (things like activate, iconize, close...). Debugging would be made a lot easier if I could identify a hook that would let me close the native window with the debugger launches, then reopen it when it proceeds - but I haven't a clue how that code works. Anyhow, I have a native window that opens with a sketch morph in it and it does pretty much what I expect. Because of the OS doing window image caching and its own damage repair from an offscreen buffer - it feels wicked fast and responsive compared to our emulated windows. I would like to push on this and bid farewell to our MDI-like interface of windows within a window and finally switch to native windows with a top level morph in each. I have some very mixed feelings about this as the window theming work that has been done is really top notch. Absolutely wonderful - and yet I'd like to throw it all away and go with the OS windows because they're about a zillion times faster and more responsive (my wicked fast 2GHZ Macbook Pro has about a half second delay to drag a window - seriously - why?). It works OK on the Mac OS X. I'd like to find a windows and linux person who would also like to work on this. I have no idea if it works on other platforms. I also have no idea how I'm going to extract my changes and ship them. I've had to hack HandMorph>>processEvents and lord knows what else in the quest to make this fly. I suppose I could file out a change set? Anyhow - it sort-of works except I think I've exposed a bug in event coordinate translation and I don't understand mouseFocus and keyboardFocus - how is that suppose to work? Or does it anymore? Perhaps the folks who worked on recent event tweaks could enlighten me? -Todd Blanchard

Aug. 17, 2009

Re: [Pharo-project] Problem with Author

by Mariano Martinez Peck

2009/8/17 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com> > El lun, 17-08-2009 a las 16:42 -0300, Mariano Martinez Peck escribiÃ³: > > Hi folks: I think I found a little bug with the Author refactor. To > > reproduce: > > > > 1) Open Monticello browser > > 2) select a package you modified something, select a repository and > > press save > > 3) The popup asking you the full name and surename is opened. The > > thing is that if you press cancel, it closes the popup but another one > > is opened :( yo have no other choice that put "ok" > > > Yes, this is how the original prompt for initials worked before the > rewrite, I didn't modify it. > The thinkg is, it keeps asking until you enter something. > > If you could press cancel, when you do other modification, it will > prompt again, so I prefer to keep the old behavior of a continuous > asking for full name. > > But this could be changed, of course. What should be the behavior? The behavior must be just cancel. Close the popup and do nothing. Not to open the popup again. > > > > > Can anyone reproduce this ? If so, I'll open a bug ticket. > > > > Best, > > > > Mariano > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 17, 2009

Re: [Pharo-project] Problem with Author

by Alexandre Bergel

> I suppose you refer to the last time you enter your name on *other* > image as if it is the same image, it won't ask for the full name as > already have it. Exact. > I think that someone (maybe you) asked for the capability of storing > the > full name on the computer disk and if found it will pre-fill the > prompt. That was an idea yes. > I can add this to the author code, but just need to ask if: > - is there a convention for storing squeak/pharo settings e.g. in > linux > could be a .squeak/ or .pharo/ folder on the $HOME of the user. In > windows I suppose that in my documents but I really don't use it so I > don't know. I would not rely on this. I usually have my images a bit everywhere. and move frequently them around. > - is there a convention for storing this files besides the > image/changes/sources files. This is as the current pharo/squeak > works, > I think. next to the image will make me happy. > - the preference browser has the capability of storing the preferences > in a file. Maybe this could be reused and include the full name and > try > to read from there on first full name prompt. Could be yes > Will be useful to other users to have this, supposing the they change > image often, or the hassle of writing by hand once for image it is > negligible? It will be useful for me yes Alexandre > >> Like this, I just have to press 'Ok'. >> >> Alexandre >> > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 17, 2009

Re: [Pharo-project] assert:includes

by Daniel P Zepeda

I sent this to Mr. Leon, and this was his reply: You're not running the latest sUnit. Find and load sUnit Enhanced which has a better UI and includes these methods. Bleh, DZ On Aug 17, 2009, at 3:45 PM, Daniel P Zepeda wrote: > Oh, so you guys are saying that this was a convenience selector that > was added in the image I was using which was never in Pharo. I hadn't > thought about that, I thought it had something to do with differences > in argument precedence, which seems to be a more basic issue between > Pharo and Squeak. Since I totally went with Pharo, I removed all of > the Squeak images I had, so I don't know if that convenience selector > was in the image I was using or not. > > If it was a convenience selector, I'm glad it was removed, I wouldn't > have expected that behavior. I guess I should just make a change set > and send it to Mr. Leon to do with what he wants to, as I said the > workaround is trivial. > > DZ > On Aug 17, 2009, at 11:45 AM, Adrian Lienhard wrote: > >> I quickly checked in Squeak 3.9 and 3.10 but they do not have that >> method either. So chances are high that this method never was in >> Pharo. Maybe it was added by some other package as an extension. >> >> Cheers, >> Adrian >> >> On Aug 17, 2009, at 18:32 , Henrik Sperre Johansen wrote: >> >>> I can't remember this change specifically, but to me it seems like a >>> method was removed from Pharo that just added slight syntactic >>> sugar. >>> I'd reckon the reasoning was that it was not in some "standard" >>> SUnit, >>> and thus keeping it lead to worse portability to Smalltalks other >>> that >>> Squeak. (For example, it does not exist in VisualWorks) >>> A case could be made that the method should have been deprecated >>> rather >>> than removed, but done is done, and all that :) >>> >>> Cheers, >>> Henry >>> >>> On 17.08.2009 18:17, Daniel P Zepeda wrote: >>>> Greetings, >>>> >>>> I've run across this in my own tests that ran fine in Squeak, but >>>> failed in Pharo. I thought it was just me being a dummy, but when I >>>> imported SandstoneDb and ran the tests, the exact same thing >>>> happens. >>>> It is a simple fix, but being fairly new at this, I'd like to know >>>> why >>>> this is, and if I should have to do this or not. >>>> >>>> So, for easy reference, I loaded the latest SandstoneDb (rjl.117) >>>> into >>>> my image (pharo1.0beta-10401web09.07.5) and ran the tests, several >>>> of >>>> which failed with a doesNotUnderstand: #assert:includes: >>>> >>>> Here is the test: >>>> >>>> testCollectionSerialization >>>> kid save. >>>> mom children: (OrderedCollection with: kid). >>>> mom save. >>>> self flushAndReload . >>>> self >>>> assert: mom refreshed children >>>> includes: kid refreshed >>>> >>>> if I simply put parens around the argument to assert: like this: >>>> >>>> assert: (mom refreshed children >>>> includes: kid refreshed) >>>> >>>> it passes. In all cases of failing tests with SandstoneDb, that is >>>> the >>>> case. Any insight here? >>>> >>>> Thanks! >>>> DZ >>>> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 17, 2009

Re: [Pharo-project] Squeak versus Pharo as application name

by Marcus Denker

Hello, I cleaned the menues, and moved things into the first menu that normally are there for all other Mac apps. For example all the Quit entries, "About" and "Preferences". Now, all these are not about "Squeak VM", but about "Pharo". So I checked a bit to see how Sophie had a nice Sophie menu, and I found that changing the info.plist would change the menu. I than stopped. So now we need to think about what to do. Do we want a "Squeak VM" menu with a "Preferences" entry that than is not about "Squeak VM"? I don't think so... Marcus On 16.08.2009, at 20:25, John M McIntosh wrote: > > On 16-Aug-09, at 2:50 PM, StÃ©phane Ducasse wrote: > >> The point is that pharoers should implement the vision not pharo. >> We have enough to do. The fact that pharo will succeed depends also >> on >> us as >> a community nor just 5 guys doing an integration of fixes. >> >> Stef > > Ok let's talk about bug http://code.google.com/p/pharo/issues/detail?id=1068&q=quit&colspec=ID%20Ty… > > Part of this is the *purge* of the string Squeak from the image, so > Quit Squeak Vm doesn't fire the quit logic > > (a) I'd rather not have to build two VMs, one for Squeak and one for > Pharo > (b) Also I'd rather not have to answer is the Pharo VM different from > the Squeak VM? > (c) If you take the Squeak.app and rename it all to Pharo then someone > has to manage that process and ensure the Pharo clone is cloned > properly from the Squeak.app > (d) if you have a Pharo.app the question then is where did it come > from? > (e) I do agree having a Pharo app, then seeing quit Squeak VM is very > confusing, therefore people should be able to change that to suit > their needs. > > So how would people like to see how this would work. > > This of course precludes any discussion of how the linux & windows > versions behave and give textual feedback. > > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 17, 2009