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

Re: [Pharo-project] looking for Unicode testers

by Michael Rueger

Hilaire Fernandes wrote: > Does not work here. > > My system is LANG=fr_FR.UTF-8 > > My keyboard keying is us_intl, (accented character are composed), this > set up is used to work with standard pharo and ecoding to latin1 Are you using ubuntu? I have a hard time setting up the keyboard for compositing. > When I open the FileBrowser on a folder 'ici et lÃ ' it is ok. Hoever > there are some random error related to #pathParts message sent to an > undefined object. If you could send me some error logs that would be great. > Next, in pharo.sh, the encoding is set to latin1, why ? I removed it > before the test. Forgot to take it out, I invoked the VM and image "manually"... Michael

Feb. 9, 2009

Re: [Pharo-project] [ANN] prebuild image #10231

by Igor Stasenko

2009/2/9 Michael Rueger <m.rueger(a)acm.org>: > Marcus Denker wrote: >> http://gforge.inria.fr/frs/download.php/17057/Pharo0.1Core-10231.zip > > Wouldn't it make sense to set the display to little endian rather than > big endian with all those intel machines out there? > I poked with this logic a little, trying to understand how to make bits ordering be same as platform. But its quite confusing. I'm not really happy seeing in C sources, a routines which reordering bitmap bytes before putting them on screen, and then reverting them back. See ioShowDisplay(), reverse_image_words(), reverse_image_bytes() functions. If depth filed of form is negative, it indicates that form's bitmap is stored in little endian format, and if positive - in big endian. > Michael > > _______________________________________________ > 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.

Feb. 9, 2009

Re: [Pharo-project] MIME Bug in 10229

by Michael Rueger

StÃ©phane Ducasse wrote: > When you drag and drop a cs file you get a DN > callGetMimeTypeOrNilForFileExtension: > > http://code.google.com/p/pharo/issues/detail?id=510 attached a fix there. Disabled the Mac specific part for now as the default Pharo image does not have FFI included. Should be moved into a future version of the directory plugin. Michael

Feb. 9, 2009

Re: [Pharo-project] [ANN] prebuild image #10231

by Michael Rueger

Marcus Denker wrote: > http://gforge.inria.fr/frs/download.php/17057/Pharo0.1Core-10231.zip Wouldn't it make sense to set the display to little endian rather than big endian with all those intel machines out there? Michael

Feb. 9, 2009

Re: [Pharo-project] Concerning issue #264

by Igor Stasenko

2009/2/9 Marcus Denker <denker(a)iam.unibe.ch>: > > On 08.02.2009, at 18:13, Igor Stasenko wrote: > >> Hi Markus, >> >> i have some comments about morphs :) >> >> To my personal feel, a drop shadow feature (and all what is connected >> with it) is quite controversial, >> i don't think its worth promoting hasDropShadow shadowOffset to ivars. >> Instead, i think its worth demoting these ones to a void! :) >> > > What I wanted to say is that now certain state that is accessed on > *every redraw* > is kept in a dictionary in MorphExtension, while at the same time > there are instance > variables in MorphExtension that are never used at all. > > So I think we would get some speedup by just storing the state that > morhic accesses now on > every redraw into iVars (while cleaning up, e.g. removing etoys > related state or checking if it really > makes sense to have both balloonText amd balloonTextSelector as > iVars...). > > This would not be a real cleanup. It's exactly some small thing of the > kind that is easy to not do > "because it can be done even better"... > I was mistaken, i thought you were talking about putting into Morph ivars , not MorphExtension. Sure, putting ivars into MorphExtension does not hurt anyone, because it doesn't makes it better or worse :) I still doubt that placing them in ivars will affect performance that you will notice it. Mainly because there are many other things in event handling and drawing that take a times more cycles. >> Can anyone tell me why morph (and moreover - canvas) should be aware >> of a shadows effect? > > No idea... I am not a specialist for graphics stuff. To me, morphic > looks > like an experiment abandoned while it was heavily hacked to meet the > daily > needs of etoy-development. A lot of stuff seems to be hacked into it > in a hurry, > and many things where never improved "because one could do even > better". Which > of course lead to nothing beeing done at all. > I think this happens because there is no dedicated people, like Gary who constantly paying attention on improving this part of Squeak. When we develop in jump-in-then-jump-out style, we really don't care about improving - just writing a code and make sure it works, and then leaving it rot there, because this part is not interesting and not exciting at all :) > Marcus > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > 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.

Feb. 9, 2009

[Pharo-project] [ANN] prebuild image #10231

by Marcus Denker

http://gforge.inria.fr/frs/download.php/17057/Pharo0.1Core-10231.zip ------------------------------------------------------ update10226 - Issue 483: [Pending Etoy Cleaning] Morph>>actorState remove actorState ------------------------------------------------------ update10227 ssue 482: [Pending Etoy Cleaning] Object>> uniqueNameForReferenceOrNil ------------------------------------------------------ update10228 Monticello merged loader changes (mike rueger) MonticelloConfigurations merged with impara MonticelloConfigurations- jl.43 mainly adds "atomic" loading ScriptLoader adding configuration map loading support ------------------------------------------------------ update10229 Network packages reorganisation by mike rueger - loaded as MCConfig ------------------------------------------------------ update10230 Issue 506: fix: remove #baseUniclass Issue 508: fix: clean StandardScriptingSystem more Issue 507: remove #setNumericValue: ------------------------------------------------------ update10231 -------------- Small Etoy cleanup -> remove class Player -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Feb. 9, 2009

[Pharo-project] [update] #10231

by Marcus Denker

10231 ==== Small Etoy cleanup Class removed: Player Methods removed: SmallInteger #uniqueNameForReference PasteUpMorph #printScriptSummary SmartRefStream #restoreClassInstVars ScriptLoader #cleanUpEtoys Presenter #goButtonState: #reportPlayersAndScripts #startRunningScripts #startRunningScriptsFrom: #uniclassesAndCounts -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Feb. 9, 2009

Re: [Pharo-project] Concerning issue #264

by Marcus Denker

On 08.02.2009, at 18:13, Igor Stasenko wrote: > Hi Markus, > > i have some comments about morphs :) > > To my personal feel, a drop shadow feature (and all what is connected > with it) is quite controversial, > i don't think its worth promoting hasDropShadow shadowOffset to ivars. > Instead, i think its worth demoting these ones to a void! :) > What I wanted to say is that now certain state that is accessed on *every redraw* is kept in a dictionary in MorphExtension, while at the same time there are instance variables in MorphExtension that are never used at all. So I think we would get some speedup by just storing the state that morhic accesses now on every redraw into iVars (while cleaning up, e.g. removing etoys related state or checking if it really makes sense to have both balloonText amd balloonTextSelector as iVars...). This would not be a real cleanup. It's exactly some small thing of the kind that is easy to not do "because it can be done even better"... > Can anyone tell me why morph (and moreover - canvas) should be aware > of a shadows effect? No idea... I am not a specialist for graphics stuff. To me, morphic looks like an experiment abandoned while it was heavily hacked to meet the daily needs of etoy-development. A lot of stuff seems to be hacked into it in a hurry, and many things where never improved "because one could do even better". Which of course lead to nothing beeing done at all. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Feb. 9, 2009

[Pharo-project] Fwd: warnIfNoSourcesFile doesn't work as desired

by StÃ©phane Ducasse

> Gwenael > > can you look at http://code.google.com/p/pharo/issues/detail?id=512&colspec=ID%20Type%20Sta… > > > Issue 512: warnIfNoSourcesFile doesn't work as desired > â¹ Prev 164 of 164 > 1 person starred this issue and may be notified of changes. Back > to list > Status: New > Owner: ---- > > > Add a comment and make changes below > > Reported by jmmcintosh, Today (2 hours ago) > > If you have the case where the sources file is not readable, when > the opensource file logic runs it > first attempts to find the file by reading the directory, it does > see the file name, but that is no guarantee the file is readable. > Then it attempts to open the file read only, this fails but causes > the FileDoesNotExistException to run that presents you with a list > of file names & cancel. > > However if you *had* warnIfNoSourcesFile set to false, now you are > being hassled with a prompt > when in fact you've said, no I don't want warnings if the source > file isn't there or unreadable. > > Stef > > > > > > >

Feb. 9, 2009

Re: [Pharo-project] another slice for popups cleaning and some questions

by StÃ©phane Ducasse

On Feb 8, 2009, at 11:57 PM, Alain Plantec wrote: > Hi all, > I've uploaded another slice for popup and co cleaning > (SLICE-MorePopUpAndCustomMenuCleaning-alain_plantec.1) > - it Removes last PopUpMenu references. > - it Removes some of CustomMenu uses (wherever it is possible to > replace > it with a simpler UIManager dialog). Excellent > > > I've three questions: > - EmphasizedMenu is never used, can we remove it ? I imagine > - MorphicUIManager is subclassed by PSUIManager which is now the > default UIManager. Several MorphicUImanager methods are > redefined in PSUIManager. So I guess one can simply remove > MorphicUIManager versions. Is it ok to do so ? (as an example, > #chooseDirectory:from:, in MorphicUIManager, the code is using > FileList > but now we have the PSUIManager version) this is the question of how far Polymorph should be integrated. For me I would really remove the old code when it is not good. Ideally I would like to see what can be moved from polymorph to base Morphic in the case we would like to have several Polymorph like frameworks. Then I would clean part of Morphic that are not used or left over of experiements. But this would be good to discuss that > - last unrelated question, I've also seen that ListParagraph is never > used, can we remove it ? Do not know > > > now I am about to see how to kill MVCMenuMorph Good > > > cheers > alain > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 9, 2009