- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Plugin organization

by Adrian Lienhard

Hi Stef, On Feb 7, 2009, at 14:40 , StÃ©phane Ducasse wrote: > I would like to use the seaside convention so is it ok for you? > Then I will proceed and rename eveyrthing. What would be the resulting packages? I.e., how would you map the Top and Rest parts to the existing structure we have? I think that decision should be well considered as it has quite some impact (e.g., on the number of class categories and packages). I discussed with Lukas about the Seaside packaging scheme documented at http://code.google.com/p/seaside/wiki/PackageNaming The conclusion was that for Pharo the top level and the Platform level may not make much sense and could be left out. Then we would have a scheme like (Purpose-)Rest where Purpose = Tests, Examples, .. Rest = Kernel, Collections, Network, ... Note that this is the *package* structure (what you see in MC), not the class category structure. The latter could be more fine grained at the lower level (e.g., Tools-Debugger, Tools-Inspector, ... as it is structured now). The consequence would be that we have packages like Kernel Collections Tools ... Tests-Kernel Tests-Collections Tests-Tools I'm not convinced that this is the right structure, though, as we end up with lots of Test-xyz packages. As an alternative, I can imagine the package scheme Top-Rest where we have a very coarse grained Top level. For instance, we would have the following Top items: Kernel Graphics Libraries Tools Tests This means, we would have packages like Kernel-Numbers Kernel-Traits Kernel-Compiler ... Libraries-Collections Libraries-Regex Libraries-Network ... Tests-Kernel Tests-Libraries ... I'm curious if there are other ideas around. One way or the other, we need to clean this up. Right now it is a mess. E.g., there is a top level package MethodFinder, while all other tools are in the Tools package. Cheers, Adrian > > > stef > > On Jan 31, 2009, at 10:51 AM, StÃ©phane Ducasse wrote: > >> I like the seaside organization >> >> Top-(Purpose-)(Platform-)Rest >> >> * Seaside-Canvas contains he canvas implementation. >> * Seaside-Squeak-Canvas contains the platform specific code of >> the canvas implementation. >> * Seaside-Examples-Canvas contains example code showing off the >> canvas implementation. >> * Seaside-Tests-Canvas contains the tests for the canvas >> implementation. >> * Seaside-Tests-Squeak-Canvas contains the platform specific >> tests of the canvas implementation. >> >> On Jan 30, 2009, at 3:54 PM, Adrian Lienhard wrote: >> >>> >>> On Jan 30, 2009, at 15:33 , Michael Rueger wrote: >>> >>>> StÃ©phane Ducasse wrote: >>>> >>>>> so what are the organizations we can use? >>>>> Ideally I would like to have the test associated with their >>>>> packages. >>>>> >>>>> XXX >>>>> XXXTests >>>> >>>> The problem with that naming scheme is that then the tests would >>>> always >>>> be loaded together with their tests because of the simple string >>>> matching Monticello does. >>>> Which isn't something you want when doing application/runtime >>>> builds. >>>> >>>> That's why I proposed the Plugin-* and Tests-* naming schemes. >>> >>> +1 >>> >>> Adrian >>> _______________________________________________ >>> 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

Feb. 9, 2009

Re: [Pharo-project] looking for Unicode testers

by Michael Rueger

Chris Kassopulo wrote: > On linux pasting Ã¤ or Ã© from that same webpage gives > "Error: Invalid utf8 input detected" That's probably due to the left-over encoding setting in Pharo.sh. The encoding line needs to be removed. > How do I input those characters from the keyboard? You need to switch to a different keyboard layout. Compositing should also work, but I currently don't know how to activate that either ;-) Michael

Feb. 9, 2009

Re: [Pharo-project] looking for Unicode testers

by Michael Rueger

Lukas Renggli wrote: >> It is the pharo one click with a modified (slightly outdated) image and >> an updated Unix VM. > > The one-click thing does not work on my Mac, nothing happens. I can > open the image with another VM though. > > Is this a special VM that comes with the one-click image? I might miss > the context. I simply took the one click I had downloaded, so I wonder if it ever worked on Mac? According to the system log it always tries to launch "squeak", even though I changed the entry to point to the newer VM from the Squeak.org download. > Pressing any key-combination with the apple-key raises an error > "MessageNotUnderstood UndefinedObject>>#<". It seems that slot six is nil when any modifier is pressed? John? > Pasting most of the texts from this website > <http://www.columbia.edu/kermit/utf8.html> raises an error: "Invalid > utf8 input detected". Hmm, is the clipboard encoding UTF-16 on Mac? Thought it was UTF-8... Michael

Feb. 9, 2009

Re: [Pharo-project] a question about method browsers in pharo

by David RÃ¶thlisberger

Hi Oscar, > If I enable halos and explore the morphs, I see that the first one has > as its model an OBImplementorsBrowser, and the second an > OBMethodListBrowser. Why not simply use the latter? I searched for > references to both, but did not immediately see how to change the > behaviour on <cmd>-m. I think it is the other way around: In the workspace you get the OBMethodListBrowser and in the class browser the OBImplementorsBrowser? The reason for this is that the workspace passes the request to the SystemNavigation class. After this class has gathered the set of messages to display, it passes this set to a method opening the so called message set browser which can only reason about a set of methods, not about whether these are senders or implementors. That's why we get a generic message list browser there but a dedicated implementors browser in OB. So we need to change SystemNavigation to achieve the same result in both scenarios. I can propose a change set. David

Feb. 9, 2009

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