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

Re: [Pharo-project] Question about MD5

by Mariano Martinez Peck

On Sun, Aug 16, 2009 at 6:53 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > 1) commit the hole package to PharoInbox repo > > > > But I don't know how to tag it as 1.0 > if you start to add a tag you should get a list. > This is a google shitty interface (tm) > Ahh okok. Now I found it. The thing now is...where I commit these change? (see my last email) Thanks Mariano > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 16, 2009

Re: [Pharo-project] Question about MD5

by StÃ©phane Ducasse

> 1) commit the hole package to PharoInbox repo > > But I don't know how to tag it as 1.0 if you start to add a tag you should get a list. This is a google shitty interface (tm)

Aug. 16, 2009

Re: [Pharo-project] Bug or remnant to be stripped out?

by StÃ©phane Ducasse

I think that gary needs it for its clients. Now the WorldMainMenuBar should not depend on ClockMorph which is a goody for example. There is a clear lack of registration for the worldMenuBar. Stef On Aug 16, 2009, at 10:27 PM, csrabak(a)bol.com.br wrote: > When the main dock bar is enabled in a Pharo1.0beta #10414 update, > an attempt to load updates from the Configuration->update from > server entry leads to a MNU: > > TheWorldMainDockingBar(Object)>>doesNotUnderstand: #updateFromServer > Receiver: a TheWorldMainDockingBar > Arguments and temporary variables: > aMessage: updateFromServer > exception: MessageNotUnderstood: > TheWorldMainDockingBar>>updateFromServer > resumeValue: nil > Receiver's instance variables: > a TheWorldMainDockingBar > . > > . > > . > > Is this a bug or or the issue is that main dock was supposed to be > removed? > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 16, 2009

Re: [Pharo-project] ORM for Pharo -- Â½ OFF

by StÃ©phane Ducasse

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 > Stef, > > I understand you agree with Mariano. Now how will Pharo fulfill > this vision? > > -- > > Cesar Rabak > > PS.: See also my reply to Mariano > > Em 16/08/2009 06:12, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr > > escreveu: > > > +1 > > On Aug 15, 2009, at 1:42 AM, Mariano Martinez Peck wrote: > > > > > > > 2009/8/14 > > > > Mariano, > > > > I agree (and I myself have been on the Research side getting answers > > similar to those ones) in fact I'll add another item to your list: > > > > -- They have an "architectural steering committee" that dictates use > > of some RDBS > > > > I've seen this even requiring some ERP used different database > > engine thas suggested by supplier. . . > > > > So if we want to compete with enterprise applications we need to get > > into some Enterprise: > > > > We're still thinkering with printing in Pharo (and this is PITA when > > attempting to be platform agnostic), so no Report Generator still, > > no matter how well you connect to a RDBS, any slightly above trivial > > example CRUD application will need this support. > > > > Our present set of widgets is sleek but still not as comprehensive > > as the other competing approaches, and we still have not created > > enough baseline to have an "echo system" so third parties can > > augment them as it happens now with Java, .Net and happened (and > > still as legacy updates) in Delphi and VB. > > > > So if the goal is to reach those enterprise trench we have to find > > some company that would profit of having [Pharo] Smalltalk as a > > primary language to customize or augment their system, as today (say > > as sake of example, SAP has ABAP but with Netweaver is going Java, > > and they competitors similar path). > > > > Let's think about this: historically some (comercial) Smalltalks > > allowed via OLE (a.k.a. COM, etc.) to ac cess Microsoft Office > > features and do things similar as VB (in fact even Tcl and Python > > allow that), but what is the "productivity" of programmer that finds > > a tutorial or an example in VB and has to "translate" it to > Smalltalk? > > > > As today can we enumerate what would be an advantage of doing > > something in Pharo instead of some "mainstream" language just to do > > some GUI painting CRUD application? > > > > I don't know if I understand you. The idea and goal behind Pharo is > > to have the open, free, clean and robust smalltalk that we were > > missing for years for commercial applications. At least that's my > > idea of Pharo. It must be a platform and a base where you can create > > tools in it and with both of them create real applications. > > > > In my opinion Pharo shouldn't be associated with a particular UI > > (web or desktop) neithe r to a persistence strategy. Pharo must be > > the base of all that. So then you can have differents alternatives: > > For UI's you can have PolyMorph and the UI Builder. For Web you can > > have Seaside and Aida/Web. But pharo is not coupled with any of > > them. You will then choose the solutions that best feets your needs. > > > > In summary, I would love to use Pharo as platform to build > > enterprise and commercial applications. No matter how do I persist > > or display my objects. > > > > Best, > > > > Mariano > > > > > > > > > > again my 0.01999.... > > > > Regards, > > > > -- > > > > Cesar Rabak > > > > > > Em 14/08/2009 16:57, Mariano Martinez Peck < marianopeck(a)gmail.com > > > escreveu: > > > > > > > > > > 2009/8/14 > > Esteban, > > > > I'm comenting this on philosophical grounds. > > > > I understand the efforts to have SqueakDBX and other ORM in Pharo > > are motivated by Seaside and other "production" initiatives so, > > again, my food for thought is more an intellectual contribution > > which I see as useful for Pharo as project: > > > > I don't see Pharo any time soonÂ® having all the toolset to be able > > to compete in the CRUDÂ¹ realm with more streamlined tools and > > besides, not matter how much theoretical work has been done on ORM, > > the "impedance mismatch" is still there, > > > > Hi! I am agree with you about the "impedance mismatch". I think that > > if I am free to choose a persistence strategy I would use an OODB. > > However, if we are talking about real enterprise application (not a > > simple webpage) being able to choose the persistence strategy is > > practically impos sible. We did a survey last year and the results > > were that most of the times you cannot choose. Of course, the client > > has a lot of reasons: > > > > - The client already has a RDBMS > > - They had paid for it and have the license (sometimes) > > - They want a company's support. The only company here is Gemstone. > > - RDBMS has history and it is an standard > > - They have knowledge about it > > - Interaction with other system (even legazy systems) > > - They are afraid of using another persistence strategy > > - They want to use SQL > > - They have DBAs > > - The persistence is difficult to negotiate > > > > So. In my opinion, if Pharo wants to be used really as a platform > > for enterprise applications (competing to java, .NET, etc), it must > > have a good relational solution. Of course, when you are able to > > choose, you can go for another appro ach like OODB. > > > > Best, > > > > Mariano > > a recent and practicall account of this (for Squeak) can be found in > > > > http://onsmalltalk.com/simple-image-based-persistence-in-squeak > > > > also, AIDA/Web has been able to run only storing thing in the image! > > See > > > > http://groups.google.com/group/comp.lang.smalltalk/browse_thread/thread/d3b… > > > > Since we'll increase the educational efforts to spread Pharo, I > > think that as technology we should to recover a bit of Smalltalk > > technology and be first more Object Oriented and then see if ORM > > still is so needed. > > > > my 0.0199999.... > > > > -- > > > > Cesar Rabak > > > > [1] http://en.wikipedia.org/w iki/Create,_read,_update_and_delete > > Em 14/08/2009 16:14, Esteban A. Maringolo < emaringolo(a)gmail.com > > > escreveu: > > > > > > My prototype is getting less proto, and I found out it doesn't have > > complex relations, and the system is going to perform faster if I > have > > tables for most of it. > > > > What are the choices I have for doing ORM in Pharo? > > > > Â¿Does GLORP work? Â¿Any other options? > > I don't have a strong preference for the RDBMS engine, it can be > > anything (free), being it MySQL, PostgreSQL or Sql Server Express. > > > > Best regards, > > > > Esteban A. Maringolo > > > > _______________________________________________ > > 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 > > > _______________________________________________ > 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

Aug. 16, 2009

Re: [Pharo-project] Complex number support discussion

by Schwab,Wilhelm K

I have indeed listed my objections - several times; you simply seem to not want to acknowledge the objections. Please make your pososal on the wiki, and Sig and I will respond in kind. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of csrabak(a)bol.com.br Sent: Sunday, August 16, 2009 3:01 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Complex number support discussion Wilhelm, About your point on "benefit a very small number of cases" I paraphase yourself "...is in the code that is not in your image.": if we stick to only our personal experiences and don't think about the future users of the package, we'll arrive at a 'domestic' or 'local' solution which will be useful on another set of not too many number of cases and make Pharo less than an option (for work with this kind of needs) for people that still do not use Pharo. I see you state your disagreements and do not explain on what grounds so I cannot elaborate, also as it seems the desire of the interested community to go ahead and keep the discussion on the wiki, I'll read what's there and see if is anything else I can contribute. On a separate thread I'll put on a more general terms my thoughts on the broader theme of use of Smalltalk for more numeric intensive applications and what I think we could improve in Pharo to make easier for programmers that decide the use of this platform. Em 16/08/2009 00:32, Schwab,Wilhelm K < bschwab(a)anest.ufl.edu > escreveu: Cesar, Storing integers and fractions for the real and imaginary parts of a complex number will be of benefit in a very small number of cases. Most uses of complex numbers involve transcendental functions that will not produce "nice" results in the general case. Your closing paragraphs below, well, let's just say I disagree. If you and Ken, separately or together, put proposal(s) on the wiki, I will gladly respond with comments on the pages and/or counter proposal(s), and would be glad to work with Sig on same. As for this seemingly endless chain of email rehashing the same points, I'm done. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of csrabak(a)bol.com.br Sent: Saturday, August 15, 2009 9:04 PM To: Ph aro-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Complex number support discussion Em 15/08/2009 19:21, Igor Stasenko < siguctua(a)gmail.com > escreveu: > 2009/8/16 : > > Your first example is interesting. It boils down to two design aspects: > > > > If you need Complex numbers in the same application, you need to > > refactor the code to: > > > > > length := (something positive) ifTrue:[something sqrt ] > > IfFalse: Error do: [ 5 ]. > > i'm sure you meant > length := (something positive) ifTrue:[something sqrt ] IfFalse: [ 5 ] I'm not so sure ;-) I thought your block with a five inside some kind of error message, but this is not that important. It seems you get the spirit and considering my mistake on interpreting your example your correction is OK. > > but then > #positive is a test which defined as > > positive > ^ self > 0 > > and we getting back to discussion , what is the meaning of #> or #< > operator for complex values. > NO!! Because all this discussion is being on the possibility of having an operation on a _non_ Complex number return a Complex result, so the test is kosher and you can go. _If_ you return an argument that something already was a complex number then all this argument is moot... [snipped] > > Once you put Complex in the Smalltalk paradigm, I think we should > > preserve as much as possible this design decision made at the start of the language. > > From a programming POV -4 sqrt mapping from Real to Imaginary > > (Complex) is homologous to 13 / 3 giving a Fraction. Overall is a modeling of the world. > > > > BTW, this is why I think having Complex to only have Float mem bers > > is not a nice design decision... > > > ageed. Its can hold any values representing the value from a Real set. > But as soon as one of its member start holding someting different > (Complex) - you are in trouble. It depends. My reasoning was that if we maintain the members as two numbers in Smalltalk sense and let the mechanisms choose the representation (actually the classes), a lot of possible problems with Complex numbers not coalescing back to real due non canceling of imaginary parts (due rounding errors) could be minimized. This could make Pharo Smalltalk more interesting than using other languages where all the problems with numerical accuracy have to be taken in account. > > I simply wanted to illustrate you that passing values to code which > not expecting the Complex values having same side effect as passing a > Complex values to members of Complex value (real/imaginary) part, and > state that its ok. I'm sorry to inform you that until now you have not achieved your intent in showing me a robust case. . . > > That's why its is good to have separation from functions which > operating with reals only and can NEVER return anything else than real > values from functions which can return complex values. I maintain my opinion that this is not helpful to make Pharo (having an implementation like this) compelling for doing work with this kind of programming. For doing this way you rather do it in a spreadsheet application that has for any function a separate one for complex numbers: it works, but is cumbersome and makes code become bulkier. A strength of OO languages is polymorphism and Smalltalk adds to it dynamic typing. The separation you advocate make these advantages be lost. -- Cesar Rabak ___ ____________________________________________ 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

Aug. 16, 2009

Re: [Pharo-project] Question about MD5

by Mariano Martinez Peck

On Sun, Aug 16, 2009 at 6:06 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > sure! My change is ByteArray which is in the package Collections-Arrayed. I thought I have to commit my changes to PharoInbox but in that repo it is not commited this package. So, what should I do: 1) commit the hole package to PharoInbox repo 2) commit the change to Pharo repo > > and you open a ticket flagged as 1.0 It is alerady opened here: http://code.google.com/p/pharo/issues/detail?id=1067 But I don't know how to tag it as 1.0 thanks Mariano > > Stef > > > On Aug 15, 2009, at 9:01 PM, Mariano Martinez Peck wrote: > > > Ok then...can I commit it in inbox? > > > > best, > > > > Mariano > > > > 2009/8/14 Henrik Johansen <henrik.s.johansen(a)veloxit.no> > > Strange, retested now. > > > > With .cs from 1065 also installed I got (first result with what I > > posted): > > Time millisecondsToRun: [500 timesRepeat: [largestByteArray hex]] > > 23267 32033 > > > > and without it: > > Time millisecondsToRun: [500 timesRepeat: [largestByteArray hex]] > > 38877 50751 > > > > Guess I tested the old version in an image without 1065 when I wrote > > the 2x :) > > > > Cheers, > > Henry > > > > On Aug 14, 2009, at 3:18 58PM, Mariano Martinez Peck wrote: > > > >> > >> > >> 2009/8/14 Henrik Johansen <henrik.s.johansen(a)veloxit.no> > >> I added a version to the issue which is almost 2x faster (for large > >> ByteArrays at least). I'm not sure if the needs of DBX are such > >> that the performance increase can justify the added uglyness (using > >> to:do: instead of do: ), but it'd be nice if you would have a look. > >> > >> Henry: Thanks for your feedback and work! I tried both solutions. > >> The one I posted, with your benchmark give me 34734. However, with > >> your version, I have 29675. > >> > >> best, > >> > >> Mariano > >> > >> > >> Cheers, > >> Henry > >> > >> On Aug 13, 2009, at 3:23 08PM, Mariano Martinez Peck wrote: > >> > >>> Ok. I opened the ticket: > http://code.google.com/p/pharo/issues/detail?id=1067 > >>> > >>> I replaced _ to := and take into considerations the henrik > >>> suggestions. > >>> > >>> Best, > >>> > >>> Mariano > >>> > >>> On Thu, Aug 13, 2009 at 9:47 AM, Henrik Johansen < > henrik.s.johansen(a)veloxit.no > >>> > wrote: > >>> Please also use (String new: (self size * 2)) writeStream instead of > >>> '' writeStream. > >>> In this case it won't lead to any noticeable performance increases, > >>> but it's good practice anyways :) > >>> > >>> I'd also argue the expected returnvalue of "hex" might not be > >>> clear as > >>> something like "asHexString" when applied to a collection (hex > >>> previously only implemented on single values), but that's a minor > >>> issue. > >>> > >>> When looking around, I also noticed WriteStream nextPut: does an > >>> unnecessary check for ByteStrings which is pretty ugly (plus, it > >>> decreases nextPut: performance for all ByteString writeStreams), > >>> filed > >>> as Issue 1065. > >>> > >>> Cheers, > >>> Henry > >>> > >>> > >>> Issue 1065 > >>> On Aug 13, 2009, at 10:32 19AM, StÃ©phane Ducasse wrote: > >>> > >>> > add a nice method comment and a couple of tests! > >>> > > >>> > Stef > >>> > > >>> > On Aug 13, 2009, at 1:26 AM, Mariano Martinez Peck wrote: > >>> > > >>> >> Hi folks: Me and the rest of the team is developing SqueakDBX > >>> which > >>> >> is a driver to talk with major databases. However, I think the > >>> most > >>> >> persistence alternatives pharo has, the best. There is no better > >>> >> solution for every escenario. So, I am also trying to get the > >>> >> PostgreSQL native driver to work in Pharo. This package depends > >>> on > >>> >> Cryptography because of MD5. I know that there were added to > >>> Pharo > >>> >> packages like System-Hashing-core, System-Hashing-SHA1 and > >>> System- > >>> >> Hashing-MD5. However, the driver doesn't work yet. But adding > >>> this > >>> >> single method: > >>> >> > >>> >> ByteArray>>hex > >>> >> | stream | > >>> >> stream _ '' writeStream. > >>> >> self do: [ :each | > >>> >> stream > >>> >> nextPut: ('0123456789ABCDEF' at: each // 16 + 1); > >>> >> nextPut: ('0123456789ABCDEF' at: each \\ 16 + 1)]. > >>> >> ^ stream contents > >>> >> > >>> >> The driver works like a charm in Pharo without needing > >>> Cryptography > >>> >> package. As far as I remember there were no MIT problem with this > >>> >> package. Because of this those packages ( System-Hashing-core, > >>> >> System-Hashing-SHA1 and System-Hashing-MD5) were integrated in > >>> Pharo. > >>> >> > >>> >> So, can I add it? > >>> >> > >>> >> Thanks > >>> >> > >>> >> Mariano > >>> >> _______________________________________________ > >>> >> 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 > >> > >> > >> _______________________________________________ > >> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 16, 2009

[Pharo-project] Bug or remnant to be stripped out?

by csrabak＠bol.com.br

Aug. 16, 2009

Re: [Pharo-project] right button still doesn't work on Windows

by Mariano Martinez Peck

On Sun, Aug 16, 2009 at 10:52 AM, Damien Cassou <damien.cassou(a)gmail.com>wrote: > Please add a comment on the bug tracker saying what should be done. > Added. Take into consideration that there is another thread with same subject talking about this. It was a problem with start up list, Adrian reopened the ticket and said: "We need to change the startup list such that the InputEventSensor comes after OSPlatform" See the other thread. Best, Mariano > > 2009/8/11 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > With Pharo beta, right button still doesn't work out of the box in > Windows. > > Instead, you have to use the wheel button. > > > > To fix it, you must evaluate: InputEventSensor installMouseDecodeTable > > > > I saw that in: http://code.google.com/p/pharo/issues/detail?id=838 > > > > The thing is...where can I put that code so that new images work out of > the > > box? > > > > Best, > > > > Mariano > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 16, 2009

Re: [Pharo-project] [update] 10414

by Mariano Martinez Peck

A good idea perhaps is to have a PharoForProduction or something like that and move the methods like cleanForProduction to that class and add to that method a piece of code that deletes the class ScriptLoader at the end. Best, Mariano On Sun, Aug 16, 2009 at 3:13 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > I get 6.8MB ;) > Cool! > > Are there any other known classes with methods that use that much > memory and are not essential? > > I wonder how much we could save if methods with the source of bitmaps > (like #warningIconContents) would be removed or saved in the changes/ > sources files (would be possible if stored as comments). > > Cheers, > Adrian > > On Aug 16, 2009, at 04:27 , Marcus Denker wrote: > > > > > On 13.08.2009, at 16:26, Adrian Lienhard wrote: > > > >> update #10414 > >> ----------------- > >> 310+311: Reorganize unit tests in a more modular way such that they > >> can be unloaded > >> > >> Now all unit tests are in the packages "Tests", "CollectionsTests", > >> "KernelTests", "MorphicTests", etc. The key point of this > >> reorganization is to make these packages really modular, i.e., they > >> can be unloaded without leaving obsolete classes behind. I also made > >> sure that SUnit with its GUI is unloadable. > >> > >> If you execute in a Pharo-core image: > >> > >> ScriptLoader new cleanUpForProduction; cleanUpForRelease > >> > >> you get an image without tests and SUnit that is 8.0 MB on disk. > >> > > > > And after deleting the ScriptLoader class, it's only 6.9 MB. > > > > Marcus > > > > > > -- > > Marcus Denker - http://marcusdenker.de > > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > > > _______________________________________________ > > 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 >

Aug. 16, 2009

Re: [Pharo-project] ORM for Pharo -- Â½ OFF

by csrabak＠bol.com.br

Aug. 16, 2009