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

Re: [Pharo-project] self halt :)

by John M McIntosh

Hah, this reminds me of a time where I put like 58 halts in some group shared code I was auditing. The next day the manager had a fit, because I screwed up coding that night. Well I repled each halt was there because the code was broken and if the programmers were thinking they were making progress, I assure you they weren't... because when the code was fixed then all the callers would be broken. Beside why did you load the developer code out of Envy anyway? Oh because it's broken and you were hoping to get the latest fixes? On 2010-02-18, at 12:46 PM, StÃ©phane Ducasse wrote: > Hi guys > > I do not know anything about BalloonBezierSimulation but it contains too many self halt. > > Do you have an idea if this is something that can be fixed? > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Feb. 19, 2010

Re: [Pharo-project] self halt :)

by csrabak＠bol.com.br

You mean other than deleting all of them? ;-) Em 18/02/2010 18:46, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr > escreveu: Hi guys I do not know anything about BalloonBezierSimulation but it contains too many self halt. Do you have an idea if this is something that can be fixed? Stef _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 19, 2010

Re: [Pharo-project] databases

by csrabak＠bol.com.br

Em 18/02/2010 13:51, Levente Uzonyi < leves(a)elte.hu > escreveu: > On Wed, 17 Feb 2010, laurent laffont wrote: [snipped] > > 3. You have a legacy (relational) database, with extensive > > reporting written for it. Use an ORM. > Relational databases are not legacy, they have features which > "modern" key-value stores don't (and won't). ORMs may ease the > programmer's work, but they tend to have bad runtime performance and > can't use (all) the features of todays RDBMSs. > Levente, I think the advice doesn't intend to imply that RDBMSs are legacy _technology_. What I understand from the text is understanding the existence of an application (or a lot of data) already using a RDBMS, and so it is legacy for the programmer with the task at hand. OTOH, if we take the features of the RDBMS is central to task at hand, (and not available to Pharo) or ORM makes performance unacceptable then it may end that Pharo should not contemplated to start with, so the point becomes moot. . . just my 0.019999.... -- Cesar Rabak

Feb. 19, 2010

Re: [Pharo-project] databases

by GÃ¶ran Krampe

Hi! Chris Muller wrote: > Hi GÃ¶ran, since this is at least the second time you've indicated > having a performance issue with Magma, I'd like to reiterate my offer > of assistance. Thanks. :) > I know it takes time to evaluate other persistence options, so I would > be surprised if you've already started off in another direction merely > because you thought nothing could be done. Indeed, and you even > indicated optimism that the slowness can probably be fixed. Given my > limited knowledge of Gjaller, it seems to me that Magma should be a > perfect fit for it, especially in terms of performance and > scalability. > > My own curiousity is brimming, you are having a performance issue, > there are many many opportunities for optimization, wouldn't you like > to talk about it? Sure, my problem is that I have a general lack of time. But I intend to try to take a serious look soon. I presume that strategies in combination with running with external server might help "enough". Getting a session takes time, I have written a second "preallocated session queue" to remove that issue, and it seems to work ok. It was a long time since I worked on this, so I don't have more details at hand right now. I need to start by rebasing on newest Magma. regards, GÃ¶ran

Feb. 18, 2010

[Pharo-project] [ANN] Hobbes for Pharo

by Pavel Krivanek

Hi, I`ve created a SqueakSource repository for the Hobbes (Highly Objectified Blue Book Equivalent Smalltalk, a virtual machine for the original Smalltalk-80 Version 2 by Xerox). Many thanks to Vassili Bykov for this great stuff and support. http://www.squeaksource.com/Hobbes.html original VisualWorks version in action: http://simberon.com/hobbes.htm Cheers, -- Pavel

Feb. 18, 2010

Re: [Pharo-project] Something I don't understand with ImageSegments

by Sheridan Mahoney

Hi all, I've been catching up on ImageSegment news, and came across this old post from January, and got interested in discovering the mindset behind the outPointers array. I re-ran Mariano's original test code, with a small change: turned 'Object new' into TestOutPointers, a new subclass of Object, with 2 inst vars and one method. I'd be interested in getting feedback on whether my guesses (in quotes below) are in the ball park. The results seem to explain why Association is not in outPointers - what is captured there in the case of adding a class is a lot like what you would need for filling in a class template. If you add an instance of a class, you just need the name of the class. Some comments I have gleaned from the ImageSegment class on outPointers : This array contains: - OOPs of all objects outside the segment that are pointed to from inside segment. - outPointers that are necessary to turn the bits in the file into objects. Here's the code: | segment external internal root | external := TestOutpointers. internal := true -> external. root := false -> internal. internal := nil. segment := ImageSegment new copyFromRoots: (Array with: root with: external) sizeHint: 5000 areUnique: true. ^ (segment outPointers ) -> (segment arrayOfRoots ) ====== result ================= { false. "object outside the segment that is pointed to from inside segment." Object. "superclass of TestOutpointers" a MethodDictionary(#tryList->a CompiledMethod(1725: TestOutpointers>>tryList) ) "MethodDictionary" #('iv1' 'iv2') "inst var names" ('testing' tryList) "method category" nil. "object outside the segment that is pointed to from inside segment." #TestOutpointers. "symbol representing name of new class" Smalltalk. "environment that TestOutpointers is assigned to" #'IST-outPointers'. "category name for TestOutpointers" true. "object outside the segment that is pointed to from inside segment." Metaclass. "for initializing class variables and instance creation messages particular to a class." Object class. "class of TestOutpointers superclass" ClassOrganizer. "need this in order to determine whether TestOutpointers has been changed in the local env" #'as yet unclassified'. "??" } -> {false->true->TestOutpointers. TestOutpointers} Any feedback would be very welcome... Cheers, Sheri -- View this message in context: http://n4.nabble.com/Something-I-don-t-understand-with-ImageSegments-tp1296… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 18, 2010

Re: [Pharo-project] Pharo User Group?

by Bouraqadi Noury

On 18 fÃ©vr. 10, at 19:36, StÃ©phane Ducasse wrote: > > On Feb 18, 2010, at 5:11 PM, Alexandre Bergel wrote: > >> Stef, >> >> Few weeks ago you said you will meet some layers at inria to know >> whether something like ESUG may be set for Pharo. Do you have any >> news? > > Yes we discussed. I'm sure that they understood what we would like > to build > and they sent us a report and we should read it :) > They suggested for example to be hosted by the OW2 consortium but I > did not have the time > to look at that. OW2 is the consortium with Fractal components and other Java software... > Else what we may end up doing is to create a french loi association > (which is understood in Europe) > to manage it. > > Stef > >> >> I am just curious. >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 18, 2010

Re: [Pharo-project] Keyboard events issue on Mac VM

by Pavel Krivanek

On Thu, Feb 18, 2010 at 11:05 PM, John M McIntosh <johnmci(a)smalltalkconsulting.com> wrote: > > On 2010-02-18, at 1:37 PM, Pavel Krivanek wrote: > >> If you press the key "a", you`ll get >> >> #(2 2534082 0 1 0 0 0 1) >> #(2 2534082 97 0 0 97 0 1) >> #(2 2534157 0 2 0 0 0 1) >> >> from the virtual machine. For "A": >> >> #(2 2536225 0 1 1 0 0 1) >> #(2 2536225 65 0 1 65 0 1) >> #(2 2536413 0 2 8 0 0 1) >> >> The only event with the information about pressed character is >> keyStroke (the fourth value is 0) so you will not know the resultant >> character because MacRoman charCode and/or utf32Code is missing (they >> are present on Linux). It is printed from >> InputEventFetcher>>signalEvent:. Am I missing something? >> >> -- Pavel > > It works as designed. > >> The only event with the information about pressed character is >> keyStroke (the fourth value is 0) > > > Is zero "ON PURPOSE" because the windows VM is unable to supply what character or unicode is being pressed at that point in time. > The keycode for the 'a' key is zero, the macroman value is 97, and the unicode value is 97. > looks fine > > I note the bug is that the key up's modifier should be 1 versus the 8. Ok, thank you -- Pavel

Feb. 18, 2010

Re: [Pharo-project] Keyboard events issue on Mac VM

by John M McIntosh

On 2010-02-18, at 1:37 PM, Pavel Krivanek wrote: > If you press the key "a", you`ll get > > #(2 2534082 0 1 0 0 0 1) > #(2 2534082 97 0 0 97 0 1) > #(2 2534157 0 2 0 0 0 1) > > from the virtual machine. For "A": > > #(2 2536225 0 1 1 0 0 1) > #(2 2536225 65 0 1 65 0 1) > #(2 2536413 0 2 8 0 0 1) > > The only event with the information about pressed character is > keyStroke (the fourth value is 0) so you will not know the resultant > character because MacRoman charCode and/or utf32Code is missing (they > are present on Linux). It is printed from > InputEventFetcher>>signalEvent:. Am I missing something? > > -- Pavel It works as designed. > The only event with the information about pressed character is > keyStroke (the fourth value is 0) Is zero "ON PURPOSE" because the windows VM is unable to supply what character or unicode is being pressed at that point in time. The keycode for the 'a' key is zero, the macroman value is 97, and the unicode value is 97. looks fine I note the bug is that the key up's modifier should be 1 versus the 8. =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Feb. 18, 2010

[Pharo-project] Namespaces

by James Foster

On Feb 18, 2010, at 12:59 PM, Miguel Enrique CobÃ¡ Martinez wrote: > El jue, 18-02-2010 a las 12:18 -0800, Dale Henrichs escribiÃ³: >> Gemstone uses an order list of dictionaries for global lookup. Each user can change the order of the list or insert their own dictionaries into the list ... makes for quite a bit of flexibility.... you can load code into a particular dictionary...and the global resolution is at compile time (you can do lookup at runtime if you wish). >> >> The advantage is that the code itself has no namespace artifacts at all. >> >> I'm mentioning this as a point of information more than a serious suggestion that Pharo adopt such an approach, though:) > > Why not, if it has been proved for a long time in Gemstone, shouldn't be > sensible to create something similar for Pharo? Or it uses some kind of > proprietary technology from Gemstone? You've heard the phrase, "Imitation is the sincerest form of flattery"? It's true! We would be delighted to see Pharo use a similar scheme for namespaces. Not only is it is an elegant approach, but its adoption by Pharo would ease the upgrade path to GemStone should the opportunity arise. For an overview of GemStone namespaces, see http://www.youtube.com/watch?v=z84n3O8YUsI. For more information see the Chapter 3 of the Programming Guide (http://seaside.gemstone.com/docs/GS64-ProgGuide-2.2.pdf) James Foster GemStone Systems, Inc.

Feb. 18, 2010