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

[Pharo-project] Magma on 1.1 one click image

by Torsten Bergmann

>I am putting together a release without underscore assignments. I changed the ConfigurationOfMagma to allow underscores before load (so it should load in Squeak/Pharo 1.0/1.1) until this is finally fixed. See "1.1r2" and #preLoadForPharo So Magma is loadable - but still comes up with a unresolved reference to FlapTab (which is not in Pharo). Hit proceed here. I think there is more work to do here since WriteBarrier also references unknown classes like "BytecodeGenerator" ... Bye T. -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

July 29, 2010

[Pharo-project] Conflic between Shout and PluggableTextMorph in Pharo 1.2

by Mariano Martinez Peck

Hi. If you try to load Shout, you will have the error: 'styler is already defined in PluggableTextMorph' The problem is that the Shut class PluggableShoutMorph subclass PluggableTextMorph. PluggableShoutMorph has its own instVar 'styler' which PluggableTextMorph doesn't have in Pharo 1.1 But in Pharo 1.2 (I don't know why) PluggableTextMorph has its own instVar 'styler'....thus, the problem. Of course, if I remove the instVar 'styler' from PluggableShoutMorph it shoud load...but I am not sure if this is the correct action. Thanks for the help in advance Mariano

July 29, 2010

Re: [Pharo-project] Pharo 1.1/1.2 and class names in Chinese

by csrabak＠bol.com.br

Em 29/07/2010 03:10, laurent laffont < laurent.laffont(a)gmail.com > escreveu: > > On Wed, Jul 28, 2010 at 6:32 PM, Nicolas Cellier > > wrote: > > > > > Once upon a time I wondered if it wouldn't be possible to > > > translate the whole sources in any language (via a Dictionary). > > > In any other language, we (think of a child) must learn to > > > "talk' to computer in computer own language... So an > > > apprentice has to learn a new language anyway Be it an english > > > computer language is thus not that important. However, one of > > > the nice properties of Smalltalk is enabling "talking" to the > > > machine in a language close to our natural language, and that > > > lowers the barriers. So the question of natural language > > > naturally arises. > > > > > > 2010/7/28 Carla F. Griggio Well, that > > last comment reminded me of something: I've read code written in > > english by people that clearly didn't > > know a lot of english, and it kept me weeks thinking that the code > > did something that it didn't (and, of course, it was more > > difficult > > to realize why the code didn't behave like it was saying :P). > > So... as writing everything in english can be a solution, it can > > be a big problem too :( > > > And a lot (majority ?) of developpers don't want to use English, or > don't understand English, or don't want to try to understand > English, or don't have the courage to try to understand English. And > they need to communicate their ideas / code with others developpers > in the same position :) I think you're heading to a position I've already discussed several years ago with Jecel (not surprisingly when he was teaching a tutorial on Smalltalk) on the issue of non native English speakers 'lose' a bit of the user friendliness of certain programming languages because they need to create a full 'dictionary' in their heads about a certain programming concept and the [foreign] language they need to memorize. He gave this example (IIRC): NNN FOR I=1 TO 120 NEXT I which for the Canadian boys he was accompanying they read as 'natural language', whereas Brazilian children had to memorize that the 'tokens' "FOR" "TO" and "NEXT" had to written in a certain syntax to create a loop in this language. The same happens in Smalltalk as most of the methods being in English, when I. Tomek in his book or introductory paper mentions that it is natural to have in Smalltalk: |rusty| rusty := Dog new. rusty bark. For a non native English speaker this syntax is tantamount to some obscure mathematical notation. > I don't like writing in French, it's not suitable for > programming. Have you ever seen WinDev code with auto-translation ? I cannot tell if it was successful or not but I remember in the seventies it was reported that in France there was an attempt to translate to French the COBOL keywords. Any account on the outcome of that? > You end with: i est un entier. x, y sont des entiers. > But I think it should be possible to have code in Chinese. I think it should be possible to have code coded in such a way it could be written in Chinese and understood [tranlated?] in any language in use in the planet ;-) Cheers, -- Cesar Rabak

July 29, 2010

[Pharo-project] what about deprecating deprecated: ?

by Mariano Martinez Peck

Hi folks. Yes, I know it sounds weird...but just read We said (don't remember when) that when we deprecate a method, we give a whole release time so that eternal packages can fix they senders. And then in the next release we remove it. For example, in Pharo 1.1 we deprecate the methodX. Then, in Pharo 1.2, we should remove it, together with the rest of methods depreacted in Pharo 1.1. How to detect the methods deprecated in Pharo 1.1? You need to take a 1.1 image and look there. But to solve this, and other problems, we have not only deprecate: but also deprecated: anExplanationString on: date in: version This is muuuch better and we can even then automate code so that it automatically removes the deprecation of a previous image. You can browse and see where each method was deprecated. It would be cool if everybody uses that method instead of deprecated. And thus, it would be cool to deprecate deprecated: hahahahaha what do you think? cheers mariano

July 29, 2010

Re: [Pharo-project] Magma on 1.1 one click image

by Chris Muller

I am putting together a release without underscore assignments. 2010/7/28 Ramiro Diaz Trepat <ramiro(a)diaztrepat.name>: > Hi fellow pharoers, > Magma fails to load from the commands on the Pharo 1.1 workspace. > In my oppinion they should be removed from the that workspace, it gives > users a sloppy impression of the release. > I don't think the image has to be sacred and untouched, we can remove 5 > lines from a workspace, it will be good for Pharo 1.1. > Aside from that minor detail, I am enormously happy and grateful to all for > this release. > Cheers > > r > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 29, 2010

Re: [Pharo-project] Books for summer (was: Time Machine)

by csrabak＠bol.com.br

LOL Books for mid year vacation, perhaps!? Em 29/07/2010 02:43, laurent laffont < laurent.laffont(a)gmail.com > escreveu: On Wed, Jul 28, 2010 at 11:45 PM, <csrabak(a)bol.com.br> wrote: Em 26/07/2010 02:39, laurent laffont < laurent.laffont(a)gmail.com > escreveu: > Â And you Â dear Pharoers, Â what will you Â read this Â summer regarding > your computing/business activity ? > Laurent, I'll wait until summer arrives then I'll report back ;-P :D Should I change the subject to "Books for winter ?" Laurent _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 29, 2010

Re: [Pharo-project] HTTP client library in Pharo?

by Francois Stephany

Hi Andrei, WebClient is probably the way to go. It is primarily developed for Squeak but I'm currently using it with Pharo 1.1. http://squeakingalong.wordpress.com/2010/05/05/webclient-and-webserver-for-… The tutorial in the Help section will help you to start. Francois On 29/07/10 18:06, Andrei Stebakov wrote: > I've been trying to find a library for Pharo/Squeak which would handle > GET/POST requests with the ability to manage cookies and deal with > https servers. > The HTTPSocket that's included in Pharo doesn't have cookies support. > I tried to find any library that handles cookies and there came up > CurlPlugin and SWHTTPClient. > SWHTTPClient page has a broken link to the source code > (http://map.squeak.org/package/15f42ec1-e93e-4bcf-ab2b-6746ae9d413f) > CurlPlugin package for Win32 that I found on the main project page > fails most of the tests and can't retrieve any http data. > I also found WebClient/WebServer library at > http://www.squeaksource.com/@QY3MLGU4hU3c8qcE/2xQek_iM which also > fails most tests after installation. > > I wonder what people in smalltalk community are using when they need > to do some web scraping when they need to keep some session in > cookies? > What would be the best library to invest time into (I am very new to Smalltalk)? > > Thank you, > Andrei -- francois.stephany(a)agilitic.com http://www.agilitic.com +32 (0)484/580.322

July 29, 2010

Re: [Pharo-project] HTTP client library in Pharo?

by Lawson English

Welcome to the wonderful world of squeak: (Robin Williams genii voice on) Vast, Cosmic Programming Powers!!!! poorlymaintainedlibraries On 7/29/10 9:06 AM, Andrei Stebakov wrote: > I've been trying to find a library for Pharo/Squeak which would handle > GET/POST requests with the ability to manage cookies and deal with > https servers. > The HTTPSocket that's included in Pharo doesn't have cookies support. > I tried to find any library that handles cookies and there came up > CurlPlugin and SWHTTPClient. > SWHTTPClient page has a broken link to the source code > (http://map.squeak.org/package/15f42ec1-e93e-4bcf-ab2b-6746ae9d413f) > CurlPlugin package for Win32 that I found on the main project page > fails most of the tests and can't retrieve any http data. > I also found WebClient/WebServer library at > http://www.squeaksource.com/@QY3MLGU4hU3c8qcE/2xQek_iM which also > fails most tests after installation. > > I wonder what people in smalltalk community are using when they need > to do some web scraping when they need to keep some session in > cookies? > What would be the best library to invest time into (I am very new to Smalltalk)? > > Thank you, > Andrei > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >

July 29, 2010

Re: [Pharo-project] CogVM as official Pharo VM?

by Eliot Miranda

Hi Lukas, On Thu, Jul 29, 2010 at 2:00 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > > 1) Cog VM seems to be aimed for x86 and 32 bits. You can read Eliot > quotes: > > "The Cog VM is a just-in-time compiler that currently supports only x86 > > So far I never felt the need for 64-bit images. > > > 3) Is it stable for production use? For example, I read that with > seaside > > there are some crashes. > > Seaside itself is not the problem, Eliot quickly fixed the remaining > issues with Continuations shortly after the open-source release of > Cog. and I still need to fix objects-as-methods but have no time right now. That's probably two to five days work to do right :/ > The problem are the sockets, they cause frequent random crashes > of the VM. > Do we have any more specific information on these socket-related crashes? (platform, crash reports, test cases, etc?) best Eliot > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 29, 2010

Re: [Pharo-project] CogVM as official Pharo VM?

by Eliot Miranda

2010/7/29 Janko MivÅ¡ek <janko.mivsek(a)eranova.si> > Hi guys, > > I would prepare a separate Pharo-Cog-Experimental one-clicks for now, to: > > - encourage Cog usage and discovering all bugs and side effects, which > will: > - let the Cog become production ready more quickly, but it: > - won't mislead people to consider Cog as production ready, because > such unintential misleading can put Cog unfairly in a bad light. > that a great approach Janko. thanks, Eliot > > Best regards > Janko > > On 29. 07. 2010 10:45, Mariano Martinez Peck wrote: > > Hi folks. Hope Eliot is reading this thread. > > > > It is time to think in Pharo 1.2 and we need to discuss if we want to > > have CogVM as the standard Pharo VM. > > > > Most of us have tried it and found it incredible fast. So it would be > > very good to take advantage of it. But I think there are a couple of > > things to be discussed: > > > > 1) Cog VM seems to be aimed for x86 and 32 bits. You can read Eliot > quotes: > > "The Cog VM is a just-in-time compiler that currently supports only x86 > > > > No effort has been made to maintain 64-bit compatibility. Apologies, > > this was unaffordable." > > > > So...how much important is this for us? do we care? and if we want to do > > it, is it "doable" ? is it less doable than the normal squeak VM ? > > > > I really would like to have 64bits VM + 64bits images in a near > > future...but hat's just my thoguhts. > > > > 2) The status of the external plugins. Are they working with Cog ? Not > > only the "core plugings" but FFI, OSProcess (I read some problems with > > it), TrueType, etc... > > > > 3) Is it stable for production use? For example, I read that with > > seaside there are some crashes. > > > > 4) Depends on heroes. I never liked this idea. It has nothing to do with > > Eliot. He is very cool and helpful. But I wonder, do we understand the > > new VM and the changes? are we able to handle and fix it even without > > eliot ? > > > > 5) Integration to VMMaker. I saw that they started to merge cog > > (actually, I think only stack vm?) to the trunk of VMMaker. This is > > really good news. I hope everything is there and merged. > > > > 6) Binaries. It seems the official released didn't come with binaries. > > So we should compile it for each OS. > > > > > > Ok..that's all my thoughts. I would really like to have a discussion > > here and see what to do.....grrrrrr you are all in holidays, aren't you? > > hahah > > > > cheers > > > > Mariano > > > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > Janko MivÅ¡ek > Svetovalec za informatiko > Eranova d.o.o. > Ljubljana, Slovenija > www.eranova.si > tel: 01 514 22 55 > faks: 01 514 22 56 > gsm: 031 674 565 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 29, 2010

Re: [Pharo-project] CogVM as official Pharo VM?

by Eliot Miranda

2010/7/29 Mariano Martinez Peck <marianopeck(a)gmail.com> > Hi folks. Hope Eliot is reading this thread. > Yes, I'm reading :) > It is time to think in Pharo 1.2 and we need to discuss if we want to have > CogVM as the standard Pharo VM. > > Most of us have tried it and found it incredible fast. So it would be very > good to take advantage of it. But I think there are a couple of things to > be discussed: > > 1) Cog VM seems to be aimed for x86 and 32 bits. You can read Eliot quotes: > "The Cog VM is a just-in-time compiler that currently supports only x86 > It is only initially aimed at x86. That's the most important platform by far from Teleplace's perspective and I suspect the majority of the community is on x86. But Cog was designed form the outset to be portable. The Cogit is architected to support other ISAs. See CogAbstractInstruction and its one subclass CogIA32Compiler. To port to another ISA you should subclass CogAbstractInstruction and implement the same protocol as CogIA32Compiler. I would love to see a CogARMCompiler and a CogPPCCompiler and encourage anyone with low-level expertise on those platforms to have a go. I'm always here to answer questions. No effort has been made to maintain 64-bit compatibility. Apologies, this > was unaffordable." > > So...how much important is this for us? do we care? and if we want to do > it, is it "doable" ? is it less doable than the normal squeak VM ? > > I really would like to have 64bits VM + 64bits images in a near > future...but hat's just my thoguhts. > I'm also thinking abut 64-bits but want to do 64-bits with a new object representation based on my 64-bit objrep for VisualWorks, which would include SmallFloat. Realistically this is a year out, because the 32-bit version of the new objrep and the pinning GC need to be implemented before I'll be able to do a 64-bit VM. But it's an obvious and logical direction to go in. 2) The status of the external plugins. Are they working with Cog ? Not only > the "core plugings" but FFI, OSProcess (I read some problems with it), > TrueType, etc... > ReentrantFFIPlugin (a.k.a. src/plugins/SqueakFFIPrims/SqueakFFIPrims.c) should work. But people need to build and test. 3) Is it stable for production use? For example, I read that with seaside > there are some crashes. > Well, it is the production VM at Teleplace so at least for one context the answer is certainly yes. There must be something obviously broken with sockets (is it all platforms or only linux?) because we use sockets intensively at Teleplace and only see problems on a single customer's machine which looks to be to do with virus protection. I'm on holiday next week and am rather busy right now, but perhaps later in August I can work with Lukas to try and sort out the socket issues. 4) Depends on heroes. I never liked this idea. It has nothing to do with > Eliot. He is very cool and helpful. But I wonder, do we understand the new > VM and the changes? are we able to handle and fix it even without eliot ? > THis is a serious issue. I need to be nagged to document the system on my blog. I mean to get to this (perhaps in September?). Alas a Smalltalk JIT is a complex beast, significantly more complex than the interpreter, and is not the easiest thing to understand or debug. So even if it is well documented it'll be more difficult to fix than the interpreter, but that's a price one has to pay for this kind of performance. > > 5) Integration to VMMaker. I saw that they started to merge cog (actually, > I think only stack vm?) to the trunk of VMMaker. This is really good news. I > hope everything is there and merged. > Cog is a fork of VMMaker. We may be able to merge at some stage, and Cog's Slang should still work with the old Interpreter. But for now, inevitably, it's a fork. I needed to add a lot of functionality to Slang to write Cog, and I didn't have the cycles to keep Interpreter up to date. That's life :) 6) Binaries. It seems the official released didn't come with binaries. So we > should compile it for each OS. > There is /no/ official release. Until Cog has stabilized and the VM maintainers have taken it up it's definitely unoffficial :) Ok..that's all my thoughts. I would really like to have a discussion here > and see what to do.....grrrrrr you are all in holidays, aren't you? hahah > two days to go :) > > cheers > > Mariano > best Eliot > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 29, 2010

Re: [Pharo-project] Extending SUnit [was Re: Autotest, proof-of-concept [was: About TDD and Pharo]]

by Henrik Sperre Johansen

On 29.07.2010 17:45, Alexandre Bergel wrote: >> Wow ! Fast !. >> >> That means it should be easy now to do a lot of exciting stuff. Show tests progression, errors/failures as soon as they occur, log several things, drink cocktails, meet beautiful girls ....that's really cool. > I will be in winter time in 1 week time. We have to enjoy now > > Alexandre Nice! Maybe it's just me, or could we not add Announcement to the end of every Announcement subclass name though? Like with the window announcement, I like them better as verbs describing the event, f.ex. someAnnouncer on: TestStarted do: [] someAnnouncer on: TestEnded send: #x to: y Cheers, Henry

July 29, 2010

Re: [Pharo-project] PluggableThemedOverflowPanelMorph(Object)>>doesNotUnderstand: #statusColor

by Mariano Martinez Peck

ok...as martin said, recompiling (change and save) PluggableButtonMorph>>#update: did the trick...weird. Now we need to include this fix ASAP in the stream.. cheers mariano On Thu, Jul 29, 2010 at 7:23 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > We need help to solve this problem....I cannot do anything as I need the > TestRunner. > > WE have http://code.google.com/p/pharo/issues/detail?id=2717 > > and http://code.google.com/p/pharo/issues/detail?id=2700 > > I tried a Compiler recompileAll but still have the same problem. > > Cheers > > Mariano > > > On Mon, Jul 26, 2010 at 11:02 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> Just try open a TestRunner. You will get a DNU and that won't let you even debug the error. >> >> Pharo core version: PharoCore-1.2-12061 >> >> I attach PharoDebug.log >> >> PluggableThemedOverflowPanelMorph(Object)>>doesNotUnderstand: #statusColor >> >> Issue: http://code.google.com/p/pharo/issues/detail?id=2717 >> >> Cheers >> >> Mariano >> > >

July 29, 2010

Re: [Pharo-project] Magma on 1.1 one click image

by Facundo Vozzi

Hi Ramiro, I don't think the image has to be sacred and untouched, we can remove 5 > lines from a workspace, it will be good for Pharo 1.1. > Or maybe, only for this version, add this line before that 5 lines: Scanner allowUnderscoreAsAssignment: true Aside from that minor detail, I am enormously happy and grateful to all for > this release. > Me too. > Cheers > regards, facundo > > > r > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 29, 2010

[Pharo-project] there are still references to PluggableButtonMorphPlus

by Mariano Martinez Peck

I am in PharoCore 12066 and there are still references to PluggableButtonMorphPlus, which doesn't exist anymore: 1) MorphicToolBuilder >> buttonClass ^ PluggableButtonMorphPlus is it ok to change it to buttonClass ^ PluggableButtonMorph ? 2) UITheme >> newButtonIn: aThemedMorph for: aModel getState: stateSel action: actionSel arguments: args getEnabled: enabledSel getLabel: labelSel help: helpText |b| b := PluggableButtonMorphPlus on: aModel getState: stateSel action: actionSel label: labelSel. .... is it ok to change it to |b| b := PluggableButtonMorph on: aModel getState: stateSel action: actionSel label: labelSel. ? 3) MorphicToolBuilderTests >> expectedFailures "Polymorph override of PluggableButtonMorphPlus>>update: makes color not being updated anymore in respond to sending #changed:. Was this an intentional change and this test is obsolete?" ^ #(testGetButtonColor) I don't know how this one should be. But it should be updated, at least the class name. Thanks Mariano

July 29, 2010

Re: [Pharo-project] PluggableThemedOverflowPanelMorph(Object)>>doesNotUnderstand: #statusColor

by Mariano Martinez Peck

We need help to solve this problem....I cannot do anything as I need the TestRunner. WE have http://code.google.com/p/pharo/issues/detail?id=2717 and http://code.google.com/p/pharo/issues/detail?id=2700 I tried a Compiler recompileAll but still have the same problem. Cheers Mariano On Mon, Jul 26, 2010 at 11:02 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Just try open a TestRunner. You will get a DNU and that won't let you even debug the error. > > Pharo core version: PharoCore-1.2-12061 > > I attach PharoDebug.log > > PluggableThemedOverflowPanelMorph(Object)>>doesNotUnderstand: #statusColor > > Issue: http://code.google.com/p/pharo/issues/detail?id=2717 > > Cheers > > Mariano >

July 29, 2010

[Pharo-project] HTTP client library in Pharo?

by Andrei Stebakov

I've been trying to find a library for Pharo/Squeak which would handle GET/POST requests with the ability to manage cookies and deal with https servers. The HTTPSocket that's included in Pharo doesn't have cookies support. I tried to find any library that handles cookies and there came up CurlPlugin and SWHTTPClient. SWHTTPClient page has a broken link to the source code (http://map.squeak.org/package/15f42ec1-e93e-4bcf-ab2b-6746ae9d413f) CurlPlugin package for Win32 that I found on the main project page fails most of the tests and can't retrieve any http data. I also found WebClient/WebServer library at http://www.squeaksource.com/@QY3MLGU4hU3c8qcE/2xQek_iM which also fails most tests after installation. I wonder what people in smalltalk community are using when they need to do some web scraping when they need to keep some session in cookies? What would be the best library to invest time into (I am very new to Smalltalk)? Thank you, Andrei

July 29, 2010

Re: [Pharo-project] Extending SUnit [was Re: Autotest, proof-of-concept [was: About TDD and Pharo]]

by Alexandre Bergel

> Wow ! Fast !. > > That means it should be easy now to do a lot of exciting stuff. Show tests progression, errors/failures as soon as they occur, log several things, drink cocktails, meet beautiful girls ....that's really cool. I will be in winter time in 1 week time. We have to enjoy now Alexandre > > > > > On 29 Jul 2010, at 11:08, laurent laffont wrote: > > > > > Hi, > > > > > > Autotest use a wrapper to count hits on changed method. Take a look at Autotest>>#findRunAndShowTestsOf > > > > > > and replace: > > > > > > counter := AutotestHitCounter on: changedMethod. <- this wraps the method > > > [aTestResult := runner run: testMethods] > > > ensure: [counter uninstall]. > > > aTestResult hitCount: counter hitCount. > > > > > > by > > > > > > aTestResult := runner run: testMethods > > > > > > > > > to check that the problem is here. > > > > > > > > > I haven't tried Cog yet. Is it working out of the box ? > > > > > > > > > > > > Laurent > > > > > > > > > On Thu, Jul 29, 2010 at 10:48 AM, Tudor Girba <tudor.girba(a)gmail.com> wrote: > > > Ah, indeed! I forgot ... sorry for the noise :) > > > > > > Cheers, > > > Doru > > > > > > > > > > > > On 29 Jul 2010, at 10:45, Henrik Johansen wrote: > > > > > > On Jul 29, 2010, at 10:40 55AM, Tudor Girba wrote: > > > > > > Hi, > > > > > > It looks like Autotest is crashing on a Cog VM/image. Any ideas as to why that happen? > > > > > > Cheers, > > > Doru > > > > > > > > > If he went for using MethodWrappers as described below, it will crash on Cog, as it does not support objects as methods yet. > > > > > > Cheers, > > > Henry > > > > > > > > > > > > On 27 Jul 2010, at 10:11, Alexandre Bergel wrote: > > > > > > Indeed I also want to log for each test: > > > - min / max / mean execution time > > > - time to first failure > > > - % of errors/failures/success > > > - run count > > > > > > That would be cool > > > > > > so with these datas we know long tests. I think about wrapping run test methods with an object which then can collect these datas. Would you go this way ? > > > (Another way is to modify TestResult / TestCase, but it's more intrusive). > > > > > > Over the last few month I intensively used method wrapper (a.k.a object as compiled method). Time to time, the image just freezes or crashes. Maybe due to the garbage collector. Modifying SUnit should not be that complex. It would be nice to turn SUnit into something more extensible. One shoot two targets. > > > > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > > > www.tudorgirba.com > > > > > > "One cannot do more than one can do." > > > > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > 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 > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > 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 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

July 29, 2010

Re: [Pharo-project] Extending SUnit [was Re: Autotest, proof-of-concept [was: About TDD and Pharo]]

by laurent laffont

On Thu, Jul 29, 2010 at 4:58 PM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > > Is Annoucements framework is synchronous or asynchronous ? If > synchronous, using Annoucements isn't less intrusive and more extensible ? > > :-) > synchronous. > http://code.google.com/p/pharo/issues/detail?id=2721 > SLICE-Issue-2721-AnnouncementsForSUnit-Alexandre_Bergel.1 in PharoInbox > > I quickly wrote this. I haven't used it yet. > Wow ! Fast !. That means it should be easy now to do a lot of exciting stuff. Show tests progression, errors/failures as soon as they occur, log several things, drink cocktails, meet beautiful girls ....that's really cool. Laurent > > Cheers, > Alexandre > > > > > > On 29 Jul 2010, at 11:08, laurent laffont wrote: > > > > > Hi, > > > > > > Autotest use a wrapper to count hits on changed method. Take a look at > Autotest>>#findRunAndShowTestsOf > > > > > > and replace: > > > > > > counter := AutotestHitCounter on: changedMethod. <- this wraps > the method > > > [aTestResult := runner run: testMethods] > > > ensure: [counter uninstall]. > > > aTestResult hitCount: counter hitCount. > > > > > > by > > > > > > aTestResult := runner run: testMethods > > > > > > > > > to check that the problem is here. > > > > > > > > > I haven't tried Cog yet. Is it working out of the box ? > > > > > > > > > > > > Laurent > > > > > > > > > On Thu, Jul 29, 2010 at 10:48 AM, Tudor Girba <tudor.girba(a)gmail.com> > wrote: > > > Ah, indeed! I forgot ... sorry for the noise :) > > > > > > Cheers, > > > Doru > > > > > > > > > > > > On 29 Jul 2010, at 10:45, Henrik Johansen wrote: > > > > > > On Jul 29, 2010, at 10:40 55AM, Tudor Girba wrote: > > > > > > Hi, > > > > > > It looks like Autotest is crashing on a Cog VM/image. Any ideas as to > why that happen? > > > > > > Cheers, > > > Doru > > > > > > > > > If he went for using MethodWrappers as described below, it will crash > on Cog, as it does not support objects as methods yet. > > > > > > Cheers, > > > Henry > > > > > > > > > > > > On 27 Jul 2010, at 10:11, Alexandre Bergel wrote: > > > > > > Indeed I also want to log for each test: > > > - min / max / mean execution time > > > - time to first failure > > > - % of errors/failures/success > > > - run count > > > > > > That would be cool > > > > > > so with these datas we know long tests. I think about wrapping run test > methods with an object which then can collect these datas. Would you go this > way ? > > > (Another way is to modify TestResult / TestCase, but it's more > intrusive). > > > > > > Over the last few month I intensively used method wrapper (a.k.a object > as compiled method). Time to time, the image just freezes or crashes. Maybe > due to the garbage collector. Modifying SUnit should not be that complex. It > would be nice to turn SUnit into something more extensible. One shoot two > targets. > > > > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > > > www.tudorgirba.com > > > > > > "One cannot do more than one can do." > > > > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > 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 > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > 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 >

July 29, 2010

Re: [Pharo-project] Request for test

by Gary Chambers

Icon looks ok on Vista. App works nicely ;-) (English here, as it should be!) Regards, Gary ----- Original Message ----- From: Mariano Martinez Peck To: Pharo-project(a)lists.gforge.inria.fr Sent: Thursday, July 29, 2010 3:24 PM Subject: Re: [Pharo-project] Request for test same here. On Thu, Jul 29, 2010 at 3:42 PM, Max Leske <maxleske(a)gmail.com> wrote: mac os 10.6.4: Icon is grey with a blue triangle in it, app runs without problems. System language is english, app language was also english. Cheers, Max On 29.07.2010, at 15:38, Hilaire Fernandes wrote: > Dear all, > > I am preparing a DrGeo release. > > I will be very please if Windows and Mac user could test it for me please. > > I need to know if the application icon is looking like a triangle and if > DrGeo UI is in French for the French users. > > Here it is: http://people.ofset.org/hilaire/DrGeo.app.zip > > Thanks > > Hilaire > > > _______________________________________________ > 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

July 29, 2010

Re: [Pharo-project] Extending SUnit [was Re: Autotest, proof-of-concept [was: About TDD and Pharo]]

by Alexandre Bergel

> Is Annoucements framework is synchronous or asynchronous ? If synchronous, using Annoucements isn't less intrusive and more extensible ? :-) synchronous. http://code.google.com/p/pharo/issues/detail?id=2721 SLICE-Issue-2721-AnnouncementsForSUnit-Alexandre_Bergel.1 in PharoInbox I quickly wrote this. I haven't used it yet. Cheers, Alexandre > > On 29 Jul 2010, at 11:08, laurent laffont wrote: > > > Hi, > > > > Autotest use a wrapper to count hits on changed method. Take a look at Autotest>>#findRunAndShowTestsOf > > > > and replace: > > > > counter := AutotestHitCounter on: changedMethod. <- this wraps the method > > [aTestResult := runner run: testMethods] > > ensure: [counter uninstall]. > > aTestResult hitCount: counter hitCount. > > > > by > > > > aTestResult := runner run: testMethods > > > > > > to check that the problem is here. > > > > > > I haven't tried Cog yet. Is it working out of the box ? > > > > > > > > Laurent > > > > > > On Thu, Jul 29, 2010 at 10:48 AM, Tudor Girba <tudor.girba(a)gmail.com> wrote: > > Ah, indeed! I forgot ... sorry for the noise :) > > > > Cheers, > > Doru > > > > > > > > On 29 Jul 2010, at 10:45, Henrik Johansen wrote: > > > > On Jul 29, 2010, at 10:40 55AM, Tudor Girba wrote: > > > > Hi, > > > > It looks like Autotest is crashing on a Cog VM/image. Any ideas as to why that happen? > > > > Cheers, > > Doru > > > > > > If he went for using MethodWrappers as described below, it will crash on Cog, as it does not support objects as methods yet. > > > > Cheers, > > Henry > > > > > > > > On 27 Jul 2010, at 10:11, Alexandre Bergel wrote: > > > > Indeed I also want to log for each test: > > - min / max / mean execution time > > - time to first failure > > - % of errors/failures/success > > - run count > > > > That would be cool > > > > so with these datas we know long tests. I think about wrapping run test methods with an object which then can collect these datas. Would you go this way ? > > (Another way is to modify TestResult / TestCase, but it's more intrusive). > > > > Over the last few month I intensively used method wrapper (a.k.a object as compiled method). Time to time, the image just freezes or crashes. Maybe due to the garbage collector. Modifying SUnit should not be that complex. It would be nice to turn SUnit into something more extensible. One shoot two targets. > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > > www.tudorgirba.com > > > > "One cannot do more than one can do." > > > > > > > > > > > > _______________________________________________ > > 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 > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > 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 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

July 29, 2010

Re: [Pharo-project] Request for test

by Mariano Martinez Peck

same here. On Thu, Jul 29, 2010 at 3:42 PM, Max Leske <maxleske(a)gmail.com> wrote: > mac os 10.6.4: Icon is grey with a blue triangle in it, app runs without > problems. System language is english, app language was also english. > > Cheers, > Max > > > On 29.07.2010, at 15:38, Hilaire Fernandes wrote: > > > Dear all, > > > > I am preparing a DrGeo release. > > > > I will be very please if Windows and Mac user could test it for me > please. > > > > I need to know if the application icon is looking like a triangle and if > > DrGeo UI is in French for the French users. > > > > Here it is: http://people.ofset.org/hilaire/DrGeo.app.zip > > > > Thanks > > > > Hilaire > > > > > > _______________________________________________ > > 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 >

July 29, 2010

Re: [Pharo-project] Request for test

by Max Leske

mac os 10.6.4: Icon is grey with a blue triangle in it, app runs without problems. System language is english, app language was also english. Cheers, Max On 29.07.2010, at 15:38, Hilaire Fernandes wrote: > Dear all, > > I am preparing a DrGeo release. > > I will be very please if Windows and Mac user could test it for me please. > > I need to know if the application icon is looking like a triangle and if > DrGeo UI is in French for the French users. > > Here it is: http://people.ofset.org/hilaire/DrGeo.app.zip > > Thanks > > Hilaire > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 29, 2010

[Pharo-project] Request for test

by Hilaire Fernandes

Dear all, I am preparing a DrGeo release. I will be very please if Windows and Mac user could test it for me please. I need to know if the application icon is looking like a triangle and if DrGeo UI is in French for the French users. Here it is: http://people.ofset.org/hilaire/DrGeo.app.zip Thanks Hilaire

July 29, 2010

Re: [Pharo-project] CogVM as official Pharo VM?

by Mariano Martinez Peck

I also agree with Janko idea. Image required changes where integrated in PharoCore 1.2. We can start soon to build Dev images using that core, and, most importantly, build a one click with Cog. Now the problem is.. 1) where to get the latest code from both, SVN and VMMaker. 2) Compile and generate binaries for each platform Who can help us with this? The only binary I saw was the one Lukas did for Mac OS but I guess it should be updated with latests fixes? Cheers Mariano On Thu, Jul 29, 2010 at 3:15 PM, David T. Lewis <lewis(a)mail.msen.com> wrote: > This is very good advice. > > Dave > > On Thu, Jul 29, 2010 at 11:15:41AM +0200, Janko Miv??ek wrote: > > Hi guys, > > > > I would prepare a separate Pharo-Cog-Experimental one-clicks for now, to: > > > > - encourage Cog usage and discovering all bugs and side effects, which > > will: > > - let the Cog become production ready more quickly, but it: > > - won't mislead people to consider Cog as production ready, because > > such unintential misleading can put Cog unfairly in a bad light. > > > > Best regards > > Janko > > > > On 29. 07. 2010 10:45, Mariano Martinez Peck wrote: > > > Hi folks. Hope Eliot is reading this thread. > > > > > > It is time to think in Pharo 1.2 and we need to discuss if we want to > > > have CogVM as the standard Pharo VM. > > > > > > Most of us have tried it and found it incredible fast. So it would be > > > very good to take advantage of it. But I think there are a couple of > > > things to be discussed: > > > > > > 1) Cog VM seems to be aimed for x86 and 32 bits. You can read Eliot > quotes: > > > "The Cog VM is a just-in-time compiler that currently supports only x86 > > > > > > No effort has been made to maintain 64-bit compatibility. Apologies, > > > this was unaffordable." > > > > > > So...how much important is this for us? do we care? and if we want to > do > > > it, is it "doable" ? is it less doable than the normal squeak VM ? > > > > > > I really would like to have 64bits VM + 64bits images in a near > > > future...but hat's just my thoguhts. > > > > > > 2) The status of the external plugins. Are they working with Cog ? Not > > > only the "core plugings" but FFI, OSProcess (I read some problems with > > > it), TrueType, etc... > > > > > > 3) Is it stable for production use? For example, I read that with > > > seaside there are some crashes. > > > > > > 4) Depends on heroes. I never liked this idea. It has nothing to do > with > > > Eliot. He is very cool and helpful. But I wonder, do we understand the > > > new VM and the changes? are we able to handle and fix it even without > > > eliot ? > > > > > > 5) Integration to VMMaker. I saw that they started to merge cog > > > (actually, I think only stack vm?) to the trunk of VMMaker. This is > > > really good news. I hope everything is there and merged. > > > > > > 6) Binaries. It seems the official released didn't come with binaries. > > > So we should compile it for each OS. > > > > > > > > > Ok..that's all my thoughts. I would really like to have a discussion > > > here and see what to do.....grrrrrr you are all in holidays, aren't > you? > > > hahah > > > > > > cheers > > > > > > Mariano > > > > > > > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > > Janko Miv??ek > > Svetovalec za informatiko > > Eranova d.o.o. > > Ljubljana, Slovenija > > www.eranova.si > > tel: 01 514 22 55 > > faks: 01 514 22 56 > > gsm: 031 674 565 > > > > _______________________________________________ > > 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 >

July 29, 2010

Re: [Pharo-project] CogVM as official Pharo VM?

by David T. Lewis

This is very good advice. Dave On Thu, Jul 29, 2010 at 11:15:41AM +0200, Janko Miv??ek wrote: > Hi guys, > > I would prepare a separate Pharo-Cog-Experimental one-clicks for now, to: > > - encourage Cog usage and discovering all bugs and side effects, which > will: > - let the Cog become production ready more quickly, but it: > - won't mislead people to consider Cog as production ready, because > such unintential misleading can put Cog unfairly in a bad light. > > Best regards > Janko > > On 29. 07. 2010 10:45, Mariano Martinez Peck wrote: > > Hi folks. Hope Eliot is reading this thread. > > > > It is time to think in Pharo 1.2 and we need to discuss if we want to > > have CogVM as the standard Pharo VM. > > > > Most of us have tried it and found it incredible fast. So it would be > > very good to take advantage of it. But I think there are a couple of > > things to be discussed: > > > > 1) Cog VM seems to be aimed for x86 and 32 bits. You can read Eliot quotes: > > "The Cog VM is a just-in-time compiler that currently supports only x86 > > > > No effort has been made to maintain 64-bit compatibility. Apologies, > > this was unaffordable." > > > > So...how much important is this for us? do we care? and if we want to do > > it, is it "doable" ? is it less doable than the normal squeak VM ? > > > > I really would like to have 64bits VM + 64bits images in a near > > future...but hat's just my thoguhts. > > > > 2) The status of the external plugins. Are they working with Cog ? Not > > only the "core plugings" but FFI, OSProcess (I read some problems with > > it), TrueType, etc... > > > > 3) Is it stable for production use? For example, I read that with > > seaside there are some crashes. > > > > 4) Depends on heroes. I never liked this idea. It has nothing to do with > > Eliot. He is very cool and helpful. But I wonder, do we understand the > > new VM and the changes? are we able to handle and fix it even without > > eliot ? > > > > 5) Integration to VMMaker. I saw that they started to merge cog > > (actually, I think only stack vm?) to the trunk of VMMaker. This is > > really good news. I hope everything is there and merged. > > > > 6) Binaries. It seems the official released didn't come with binaries. > > So we should compile it for each OS. > > > > > > Ok..that's all my thoughts. I would really like to have a discussion > > here and see what to do.....grrrrrr you are all in holidays, aren't you? > > hahah > > > > cheers > > > > Mariano > > > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > Janko Miv??ek > Svetovalec za informatiko > Eranova d.o.o. > Ljubljana, Slovenija > www.eranova.si > tel: 01 514 22 55 > faks: 01 514 22 56 > gsm: 031 674 565 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 29, 2010

Re: [Pharo-project] Extending SUnit [was Re: Autotest, proof-of-concept [was: About TDD and Pharo]]

by laurent laffont

On Thu, Jul 29, 2010 at 11:24 AM, Alexandre Bergel <alexandre(a)bergel.eu>wrote > Laurent, > > I have similar needs. I would like to extend SUnit before and after each > test method. I was wondering about this: > > - Introduce a registration mechanism in SUnit (a bit like OB commands) > - TestResult>>runCase: aTestCase can be enhanced by executing what has been > registered before and after > - A class TestCommand contains a method #before and #after. TestCommand > define inst var #currentTestCase #currentTestMethod > > Advantages: > - minor addition to SUnit > > > We could then refactor the SUnit history to use a command. > It would then be easy to have a logger or something. > > Does it make sense? > Yes, it doesn't seem hard to implement. Is Annoucements framework is synchronous or asynchronous ? If synchronous, using Annoucements isn't less intrusive and more extensible ? Laurent > > cheers, > Alexandre > > On 29 Jul 2010, at 11:08, laurent laffont wrote: > > > Hi, > > > > Autotest use a wrapper to count hits on changed method. Take a look at > Autotest>>#findRunAndShowTestsOf > > > > and replace: > > > > counter := AutotestHitCounter on: changedMethod. <- this wraps the > method > > [aTestResult := runner run: testMethods] > > ensure: [counter uninstall]. > > aTestResult hitCount: counter hitCount. > > > > by > > > > aTestResult := runner run: testMethods > > > > > > to check that the problem is here. > > > > > > I haven't tried Cog yet. Is it working out of the box ? > > > > > > > > Laurent > > > > > > On Thu, Jul 29, 2010 at 10:48 AM, Tudor Girba <tudor.girba(a)gmail.com> > wrote: > > Ah, indeed! I forgot ... sorry for the noise :) > > > > Cheers, > > Doru > > > > > > > > On 29 Jul 2010, at 10:45, Henrik Johansen wrote: > > > > On Jul 29, 2010, at 10:40 55AM, Tudor Girba wrote: > > > > Hi, > > > > It looks like Autotest is crashing on a Cog VM/image. Any ideas as to why > that happen? > > > > Cheers, > > Doru > > > > > > If he went for using MethodWrappers as described below, it will crash on > Cog, as it does not support objects as methods yet. > > > > Cheers, > > Henry > > > > > > > > On 27 Jul 2010, at 10:11, Alexandre Bergel wrote: > > > > Indeed I also want to log for each test: > > - min / max / mean execution time > > - time to first failure > > - % of errors/failures/success > > - run count > > > > That would be cool > > > > so with these datas we know long tests. I think about wrapping run test > methods with an object which then can collect these datas. Would you go this > way ? > > (Another way is to modify TestResult / TestCase, but it's more > intrusive). > > > > Over the last few month I intensively used method wrapper (a.k.a object > as compiled method). Time to time, the image just freezes or crashes. Maybe > due to the garbage collector. Modifying SUnit should not be that complex. It > would be nice to turn SUnit into something more extensible. One shoot two > targets. > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > > www.tudorgirba.com > > > > "One cannot do more than one can do." > > > > > > > > > > > > _______________________________________________ > > 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 > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > 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 >

July 29, 2010

[Pharo-project] Extending SUnit [was Re: Autotest, proof-of-concept [was: About TDD and Pharo]]

by Alexandre Bergel

Laurent, I have similar needs. I would like to extend SUnit before and after each test method. I was wondering about this: - Introduce a registration mechanism in SUnit (a bit like OB commands) - TestResult>>runCase: aTestCase can be enhanced by executing what has been registered before and after - A class TestCommand contains a method #before and #after. TestCommand define inst var #currentTestCase #currentTestMethod Advantages: - minor addition to SUnit We could then refactor the SUnit history to use a command. It would then be easy to have a logger or something. Does it make sense? cheers, Alexandre On 29 Jul 2010, at 11:08, laurent laffont wrote: > Hi, > > Autotest use a wrapper to count hits on changed method. Take a look at Autotest>>#findRunAndShowTestsOf > > and replace: > > counter := AutotestHitCounter on: changedMethod. <- this wraps the method > [aTestResult := runner run: testMethods] > ensure: [counter uninstall]. > aTestResult hitCount: counter hitCount. > > by > > aTestResult := runner run: testMethods > > > to check that the problem is here. > > > I haven't tried Cog yet. Is it working out of the box ? > > > > Laurent > > > On Thu, Jul 29, 2010 at 10:48 AM, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Ah, indeed! I forgot ... sorry for the noise :) > > Cheers, > Doru > > > > On 29 Jul 2010, at 10:45, Henrik Johansen wrote: > > On Jul 29, 2010, at 10:40 55AM, Tudor Girba wrote: > > Hi, > > It looks like Autotest is crashing on a Cog VM/image. Any ideas as to why that happen? > > Cheers, > Doru > > > If he went for using MethodWrappers as described below, it will crash on Cog, as it does not support objects as methods yet. > > Cheers, > Henry > > > > On 27 Jul 2010, at 10:11, Alexandre Bergel wrote: > > Indeed I also want to log for each test: > - min / max / mean execution time > - time to first failure > - % of errors/failures/success > - run count > > That would be cool > > so with these datas we know long tests. I think about wrapping run test methods with an object which then can collect these datas. Would you go this way ? > (Another way is to modify TestResult / TestCase, but it's more intrusive). > > Over the last few month I intensively used method wrapper (a.k.a object as compiled method). Time to time, the image just freezes or crashes. Maybe due to the garbage collector. Modifying SUnit should not be that complex. It would be nice to turn SUnit into something more extensible. One shoot two targets. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > www.tudorgirba.com > > "One cannot do more than one can do." > > > > > > _______________________________________________ > 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 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

July 29, 2010

Re: [Pharo-project] CogVM as official Pharo VM?

by Janko MivÅ¡ek

Hi guys, I would prepare a separate Pharo-Cog-Experimental one-clicks for now, to: - encourage Cog usage and discovering all bugs and side effects, which will: - let the Cog become production ready more quickly, but it: - won't mislead people to consider Cog as production ready, because such unintential misleading can put Cog unfairly in a bad light. Best regards Janko On 29. 07. 2010 10:45, Mariano Martinez Peck wrote: > Hi folks. Hope Eliot is reading this thread. > > It is time to think in Pharo 1.2 and we need to discuss if we want to > have CogVM as the standard Pharo VM. > > Most of us have tried it and found it incredible fast. So it would be > very good to take advantage of it. But I think there are a couple of > things to be discussed: > > 1) Cog VM seems to be aimed for x86 and 32 bits. You can read Eliot quotes: > "The Cog VM is a just-in-time compiler that currently supports only x86 > > No effort has been made to maintain 64-bit compatibility. Apologies, > this was unaffordable." > > So...how much important is this for us? do we care? and if we want to do > it, is it "doable" ? is it less doable than the normal squeak VM ? > > I really would like to have 64bits VM + 64bits images in a near > future...but hat's just my thoguhts. > > 2) The status of the external plugins. Are they working with Cog ? Not > only the "core plugings" but FFI, OSProcess (I read some problems with > it), TrueType, etc... > > 3) Is it stable for production use? For example, I read that with > seaside there are some crashes. > > 4) Depends on heroes. I never liked this idea. It has nothing to do with > Eliot. He is very cool and helpful. But I wonder, do we understand the > new VM and the changes? are we able to handle and fix it even without > eliot ? > > 5) Integration to VMMaker. I saw that they started to merge cog > (actually, I think only stack vm?) to the trunk of VMMaker. This is > really good news. I hope everything is there and merged. > > 6) Binaries. It seems the official released didn't come with binaries. > So we should compile it for each OS. > > > Ok..that's all my thoughts. I would really like to have a discussion > here and see what to do.....grrrrrr you are all in holidays, aren't you? > hahah > > cheers > > Mariano > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Janko MivÅ¡ek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565

July 29, 2010

Re: [Pharo-project] Autotest, proof-of-concept [was: About TDD and Pharo]

by laurent laffont

Hi, Autotest use a wrapper to count hits on changed method. Take a look at Autotest>>#findRunAndShowTestsOf and replace: counter := AutotestHitCounter on: changedMethod. <- this wraps the method [aTestResult := runner run: testMethods] ensure: [counter uninstall]. aTestResult hitCount: counter hitCount. by aTestResult := runner run: testMethods to check that the problem is here. I haven't tried Cog yet. Is it working out of the box ? Laurent On Thu, Jul 29, 2010 at 10:48 AM, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Ah, indeed! I forgot ... sorry for the noise :) > > Cheers, > Doru > > > > On 29 Jul 2010, at 10:45, Henrik Johansen wrote: > > On Jul 29, 2010, at 10:40 55AM, Tudor Girba wrote: >> >> Hi, >>> >>> It looks like Autotest is crashing on a Cog VM/image. Any ideas as to why >>> that happen? >>> >>> Cheers, >>> Doru >>> >> >> >> If he went for using MethodWrappers as described below, it will crash on >> Cog, as it does not support objects as methods yet. >> >> Cheers, >> Henry >> >> >>> >>> On 27 Jul 2010, at 10:11, Alexandre Bergel wrote: >>> >>> Indeed I also want to log for each test: >>>>> - min / max / mean execution time >>>>> - time to first failure >>>>> - % of errors/failures/success >>>>> - run count >>>>> >>>> >>>> That would be cool >>>> >>>> so with these datas we know long tests. I think about wrapping run test >>>>> methods with an object which then can collect these datas. Would you go this >>>>> way ? >>>>> (Another way is to modify TestResult / TestCase, but it's more >>>>> intrusive). >>>>> >>>> >>>> Over the last few month I intensively used method wrapper (a.k.a object >>>> as compiled method). Time to time, the image just freezes or crashes. Maybe >>>> due to the garbage collector. Modifying SUnit should not be that complex. It >>>> would be nice to turn SUnit into something more extensible. One shoot two >>>> targets. >>>> >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > www.tudorgirba.com > > "One cannot do more than one can do." > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 29, 2010

Re: [Pharo-project] CogVM as official Pharo VM?

by Lukas Renggli

> 1) Cog VM seems to be aimed for x86 and 32 bits. You can read Eliot quotes: > "The Cog VM is a just-in-time compiler that currently supports only x86 So far I never felt the need for 64-bit images. > 3) Is it stable for production use?Â For example, I read that with seaside > there are some crashes. Seaside itself is not the problem, Eliot quickly fixed the remaining issues with Continuations shortly after the open-source release of Cog. The problem are the sockets, they cause frequent random crashes of the VM. Lukas -- Lukas Renggli www.lukas-renggli.ch

July 29, 2010

Re: [Pharo-project] Autotest, proof-of-concept [was: About TDD and Pharo]

by Dennis Schetinin

2010/7/26 Alexandre Bergel <alexandre(a)bergel.eu> > Ideally, we should not tag long tests. The system should be smart enough to > characterize a test as long. If it takes more than 200ms, then it is long. > Autotest should then offer me to include long test or not in the automatic > test execution. > > Using tags means that I have to go over each method test and tag them. This > is a costly effort that is likely to not work in practice. > > Why not split the task: make SUnit support tags (which is obviously useful for so many applications) and create some auto-tagging facilities? -- Dennis Schetinin

July 29, 2010

Re: [Pharo-project] Autotest, proof-of-concept [was: About TDD and Pharo]

by Tudor Girba

Ah, indeed! I forgot ... sorry for the noise :) Cheers, Doru On 29 Jul 2010, at 10:45, Henrik Johansen wrote: > On Jul 29, 2010, at 10:40 55AM, Tudor Girba wrote: > >> Hi, >> >> It looks like Autotest is crashing on a Cog VM/image. Any ideas as >> to why that happen? >> >> Cheers, >> Doru > > > If he went for using MethodWrappers as described below, it will > crash on Cog, as it does not support objects as methods yet. > > Cheers, > Henry > >> >> >> On 27 Jul 2010, at 10:11, Alexandre Bergel wrote: >> >>>> Indeed I also want to log for each test: >>>> - min / max / mean execution time >>>> - time to first failure >>>> - % of errors/failures/success >>>> - run count >>> >>> That would be cool >>> >>>> so with these datas we know long tests. I think about wrapping >>>> run test methods with an object which then can collect these >>>> datas. Would you go this way ? >>>> (Another way is to modify TestResult / TestCase, but it's more >>>> intrusive). >>> >>> Over the last few month I intensively used method wrapper (a.k.a >>> object as compiled method). Time to time, the image just freezes >>> or crashes. Maybe due to the garbage collector. Modifying SUnit >>> should not be that complex. It would be nice to turn SUnit into >>> something more extensible. One shoot two targets. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "One cannot do more than one can do."

July 29, 2010

Re: [Pharo-project] Autotest, proof-of-concept [was: About TDD and Pharo]

by Henrik Johansen

On Jul 29, 2010, at 10:40 55AM, Tudor Girba wrote: > Hi, > > It looks like Autotest is crashing on a Cog VM/image. Any ideas as to why that happen? > > Cheers, > Doru If he went for using MethodWrappers as described below, it will crash on Cog, as it does not support objects as methods yet. Cheers, Henry > > > On 27 Jul 2010, at 10:11, Alexandre Bergel wrote: > >>> Indeed I also want to log for each test: >>> - min / max / mean execution time >>> - time to first failure >>> - % of errors/failures/success >>> - run count >> >> That would be cool >> >>> so with these datas we know long tests. I think about wrapping run test methods with an object which then can collect these datas. Would you go this way ? >>> (Another way is to modify TestResult / TestCase, but it's more intrusive). >> >> Over the last few month I intensively used method wrapper (a.k.a object as compiled method). Time to time, the image just freezes or crashes. Maybe due to the garbage collector. Modifying SUnit should not be that complex. It would be nice to turn SUnit into something more extensible. One shoot two targets.

July 29, 2010

[Pharo-project] CogVM as official Pharo VM?

by Mariano Martinez Peck

Hi folks. Hope Eliot is reading this thread. It is time to think in Pharo 1.2 and we need to discuss if we want to have CogVM as the standard Pharo VM. Most of us have tried it and found it incredible fast. So it would be very good to take advantage of it. But I think there are a couple of things to be discussed: 1) Cog VM seems to be aimed for x86 and 32 bits. You can read Eliot quotes: "The Cog VM is a just-in-time compiler that currently supports only x86 No effort has been made to maintain 64-bit compatibility. Apologies, this was unaffordable." So...how much important is this for us? do we care? and if we want to do it, is it "doable" ? is it less doable than the normal squeak VM ? I really would like to have 64bits VM + 64bits images in a near future...but hat's just my thoguhts. 2) The status of the external plugins. Are they working with Cog ? Not only the "core plugings" but FFI, OSProcess (I read some problems with it), TrueType, etc... 3) Is it stable for production use? For example, I read that with seaside there are some crashes. 4) Depends on heroes. I never liked this idea. It has nothing to do with Eliot. He is very cool and helpful. But I wonder, do we understand the new VM and the changes? are we able to handle and fix it even without eliot ? 5) Integration to VMMaker. I saw that they started to merge cog (actually, I think only stack vm?) to the trunk of VMMaker. This is really good news. I hope everything is there and merged. 6) Binaries. It seems the official released didn't come with binaries. So we should compile it for each OS. Ok..that's all my thoughts. I would really like to have a discussion here and see what to do.....grrrrrr you are all in holidays, aren't you? hahah cheers Mariano

July 29, 2010

Re: [Pharo-project] Pharo 1.1/1.2 and class names in Chinese

by Henrik Johansen

On Jul 29, 2010, at 9:23 54AM, Philippe Marschall wrote: > On 07/28/2010 10:48 PM, Alexandre Bergel wrote: >>> I'd even suggest the system to reject names and selectors not in ASCII. >> >> I agree for what has to be put in PharoCore and Pharo. However, a user lambda must be able to create a class called MaClassePrÃ©fÃ©rÃ©e if he/she wishes. Every beginner do this... > > Are you sure all your subsystems (changesets, fileouts, changes file, > Monticello, ...) are Unicode aware? Do you use Unicode normalization? If > so which one? > > Cheers > Philippe +1. Venture outside the ascii-range, and you are asking for trouble when storing code externally. AFAIK, only the .sources / .changes *supposedly* uses utf8 natively. Heck, MultiByteFileStream>>setConverterForCode uses MacRoman unless you've written the utf8 BOM-marker ... Use MultiByteBinaryOrTextStream>>setEncoderForSourceCodeNamed: , and it WILL use MacRoman for .cs or .st files no matter what the streams contents are (thankfully, there are no senders in the core image, at least) Which is weird to me, since ByteString encoding is assumed to be 8859-1, and the default fonts displays 8859-15 characters :) Change any of this however, and you will surely break some old filed-out code. TLDR; There is no overall strategy for ensuring that code will be saved externally in a unicode-compatible encoding, and it's probably impossible to implement one while maintaining backwards-compatability. If you want to stay safe, use only ASCII. If you plan to never export any code (say, use changesets or Monticello), write in whatever language you want. (well, as long as you are able to input the characters of course) Cheers, Henry

July 29, 2010

Re: [Pharo-project] Autotest, proof-of-concept [was: About TDD and Pharo]

by Tudor Girba

Hi, It looks like Autotest is crashing on a Cog VM/image. Any ideas as to why that happen? Cheers, Doru On 27 Jul 2010, at 10:11, Alexandre Bergel wrote: >> Indeed I also want to log for each test: >> - min / max / mean execution time >> - time to first failure >> - % of errors/failures/success >> - run count > > That would be cool > >> so with these datas we know long tests. I think about wrapping run >> test methods with an object which then can collect these datas. >> Would you go this way ? >> (Another way is to modify TestResult / TestCase, but it's more >> intrusive). > > Over the last few month I intensively used method wrapper (a.k.a > object as compiled method). Time to time, the image just freezes or > crashes. Maybe due to the garbage collector. Modifying SUnit should > not be that complex. It would be nice to turn SUnit into something > more extensible. One shoot two targets. > >> I also think that execution time is not the only criteria. For >> example, Autotest can have a "feedback deadline" of 2 seconds. That >> means it can run: >> - 2 tests of 1 second >> - 20 tests of 100 ms >> So knowing execution times, Autotest can run as many tests as it >> can, starting from fastest to lowest. It seems that JUnitMax do >> this way. > > Method consumption as well. A test that is fast to execute but > require a lot of memory becomes slow. > > Alexandre > >> >> >> Laurent Laffont >> >> http://pharocasts.blogspot.com/ >> http://magaloma.blogspot.com/ >> >> >> >> Cheers, >> Alexandre >> >> >> On 26 Jul 2010, at 07:44, laurent laffont wrote: >> >>> >>> On Sat, Jul 24, 2010 at 10:16 AM, Alexandre Bergel <alexandre(a)bergel.eu >>> > wrote: >>> I have been using Autotest for a while already. I greatly reduce >>> the window switching. This is cool. >>> However, I have to disable Autotest when the tests take time to >>> execute. >>> >>> >>> An idea is to be able to tag tests with pragmas to put them in >>> categories. So we can have a LongRunning category which is not run >>> by default. Like NUnit (http://www.nunit.org/index.php?p=category&r=2.2 >>> ). >>> >>> Then SUnit could be enhanced to show these categories. Useful to >>> quickly select all tests related to a project for example; or run >>> only performance tests. >>> >>> >>> How would you name the tag ? Where the implementation should go ? >>> (TestCase ?) >>> >>> >>> Laurent. >>> >>> >>> Alexandre >>> >>> >>> On 15 Jun 2010, at 21:41, laurent laffont wrote: >>> >>>> Hi Alexandre, >>>> >>>> I've reorganized Autotest to write tests. The tests now run in a >>>> thread with lower priority. Thanks for feedback. >>>> >>>> Cheers, >>>> >>>> Laurent Laffont >>>> >>>> http://pharocasts.blogspot.com/ >>>> http://magaloma.blogspot.com/ >>>> >>>> >>>> On Mon, Jun 14, 2010 at 4:52 PM, Alexandre Bergel <alexandre(a)bergel.eu >>>> > wrote: >>>> Hi Laurent, >>>> >>>> I tried to program while having AutoTest running. >>>> More importantly than the interface, I experienced some problem >>>> with long executing tests. Basically, these tests should not be >>>> executed while I am programming. Or at least in a thread of a >>>> lesser priority. Am I the only one to experience this? >>>> >>>> Cheers, >>>> Alexandre >>>> >>>> >>>> On 11 Jun 2010, at 09:02, laurent laffont wrote: >>>> >>>>> On Fri, Jun 11, 2010 at 2:29 PM, Alexandre Bergel <alexandre(a)bergel.eu >>>>> > wrote: >>>>> Hi Laurent, >>>>> >>>>> I like Autotest. It is true that I always execute the test after >>>>> modifying it. >>>>> There are three horizontal panes. Why so? Is it just to open a >>>>> debugger when necessary? >>>>> >>>>> I want to be able to open a debugger from autotest. I agree the >>>>> GUI is crap now. >>>>> >>>>> >>>>> We could imagine one standalone button instead with a green >>>>> color to say the test I just edited is green, and yellow or red >>>>> when it fails. In that case, clicking on the button open a >>>>> debugger. >>>>> >>>>> I just feel the window of autotest takes a lot of space in the >>>>> screen, without having a real benefit. >>>>> >>>>> Yes it's true. I'm still thinking on a good GUI. But I'm >>>>> learning how to make GUI now :) >>>>> >>>>> If you look at Autotest package, AutotestView is just the GUI, >>>>> so we can implement several GUI and see the best solution. I >>>>> need to take the time to do it, repository is read / write so >>>>> feel free to commit :) >>>>> >>>>> What I want to have is a dashboard docked on one side of the >>>>> screen which acts like you're driving a car. It's always >>>>> visible, you have to be able to look quickly at it as when you >>>>> check the speed of your car, adjust your drive, .... >>>>> >>>>> Also another problem with the current version if that if a test >>>>> fails, change it and fails again, you don't see it has run >>>>> (nothing moves in the GUI). >>>>> >>>>> Finally, another problem is that you see that a test has failed, >>>>> but you don't know why (SUnit TestRunner has the same problem). >>>>> I want to display the exception message too. >>>>> >>>>> Thanks a lot for feedback. >>>>> >>>>> Laurent Laffont >>>>> >>>>> http://pharocasts.blogspot.com/ >>>>> http://magaloma.blogspot.com/ >>>>> >>>>> >>>>> >>>>> Cheers, >>>>> Alexandre >>>>> >>>>> >>>>> On 3 Jun 2010, at 17:11, laurent laffont wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I've written a proof-of-concept for Autotest. Draft/crappy code >>>>>> and no tests (exploration mode :) but it loads on >>>>>> PharoCore-1.1-11383-beta image. >>>>>> >>>>>> Load it: >>>>>> Gofer new >>>>>> squeaksource: 'Autotest'; >>>>>> package: 'Autotest'; >>>>>> load >>>>>> >>>>>> Open it: >>>>>> AutotestView open >>>>>> (there's en entry in WorldMenu > Tools) >>>>>> >>>>>> And change a tested method to see the results. >>>>>> >>>>>> There's a bug I need to find, maybe someone knows: >>>>>> - Change Bag>>occurrencesOf: >>>>>> - Autotest gives: >>>>>> >>>>>> 284 run, 281 passes, 0 expected failures, 1 failures, 2 errors, >>>>>> 0 unexpected passes >>>>>> Failures: >>>>>> CollectionRootTest>>#test0FixtureIterateTest >>>>>> >>>>>> Errors: >>>>>> CollectionRootTest>>#testBasicCollect >>>>>> CollectionRootTest>>#testDoWithout >>>>>> >>>>>> but in SUnit CollectionRootTest gives >>>>>> 0 run, 0 passes, 0 expected failures, 0 failures, 0 errors, 0 >>>>>> unexpected passes ?? >>>>>> >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Laurent Laffont >>>>>> >>>>>> http://pharocasts.blogspot.com/ >>>>>> http://magaloma.blogspot.com/ >>>>>> >>>>>> >>>>>> On Thu, Jun 3, 2010 at 6:09 PM, Alexandre Bergel <alexandre(a)bergel.eu >>>>>> > wrote: >>>>>> The idea is excellent. >>>>>> >>>>>> Cheers, >>>>>> Alexandre >>>>>> >>>>>> >>>>>> On 3 Jun 2010, at 10:22, laurent laffont wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Jun 3, 2010 at 3:42 PM, Alexandre Bergel <alexandre(a)bergel.eu >>>>>>> > wrote: >>>>>>>> You may have a lot of noise. >>>>>>>> >>>>>>>> I guess that Ruby uses files as a unit of development/ >>>>>>>> deployment. The closest Smalltalk/Pharo has is the class and >>>>>>>> the package. >>>>>>>> >>>>>>>> I would suggest that TestCase which would use this feature >>>>>>>> use some pragma/method to identify/declare which classes/ >>>>>>>> packages this test depends upon. Then the "autotest" >>>>>>>> framework would register such tests and listen for changes in >>>>>>>> the given classes/packages, launching required tests whenever >>>>>>>> a change happen. >>>>>>>> >>>>>>>> Additionally, one could declare such a pragma on a single >>>>>>>> test method, when this test should be run for a specific class. >>>>>>>> >>>>>>>> Of course, you also to take care of long running tests, which >>>>>>>> you probably want to exclude from auto-testing. >>>>>>> >>>>>>> I see autotest in Pharo in a slighly different way: When I >>>>>>> press save in the Monticello browser, I have a popup menu >>>>>>> which asks me whether (i) I want to run all the tests or (ii) >>>>>>> only the tests that cover that I changed from the last version. >>>>>>> >>>>>>> Does this make sense? >>>>>>> >>>>>>> Please no popup :) What I like in ruby autotest is that I can >>>>>>> quickly look at test results if I want (or not) without stop >>>>>>> writing. Often you want to see your tests failing, as you >>>>>>> type / save code. I don't have to stop writing, click a >>>>>>> button, wait test results, go again.... testing is done in >>>>>>> background and I just see notifications whether it's OK or not. >>>>>>> >>>>>>> So test log in a Transcript is OK for me. >>>>>>> >>>>>>> >>>>>>> For autotest unit of work is file: it runs the test file which >>>>>>> has the same name as the code file, but you can customize this >>>>>>> behavior. For autotest-rails: >>>>>>> "A simplified version of Autotest heuristics in this mode >>>>>>> would be: >>>>>>> When changing a test file, only this file is run (e.g. test/ >>>>>>> unit/foo_test.rb âtest/unit/foo_test.rb). >>>>>>> When changing a model file, only associated unit test file is >>>>>>> run (e.g.app/models/foo.rb â test/unit/foo_test.rb). >>>>>>> When changing a controller file, associated functional test >>>>>>> file is run (e.g.app/controllers/foo_controller.rb âtest/ >>>>>>> functional/foo_controller_test.rb). >>>>>>> When changing a fixture file, associated unit test and >>>>>>> functional test are run (e.g.app/fixtures/foos.yml â test/ >>>>>>> unit/foo_test.rb +test/functional/foo_controller_test.rb). >>>>>>> When changing a helper file, associated functional test file >>>>>>> is run (e.g.app/helpers/foo_helper.rb âtest/functional/ >>>>>>> foo_controller_test.rb). >>>>>>> When changing application_helper.rb file all functional test >>>>>>> files are run (e.g.application_helper.rb â test/functional/ >>>>>>> *_test.rb). >>>>>>> When changing a file under the config directory, all tests are >>>>>>> run." >>>>>>> >>>>>>> Laurent >>>>>>> >>>>>>> >>>>>>> >>>>>>> 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 >>>>>> >>>>>> -- >>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>> 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 >>>>> >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> 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 >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> 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 >>> >>> >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> 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 >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> 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 > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > 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 -- www.tudorgirba.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."

July 29, 2010

Re: [Pharo-project] Pharo 1.1/1.2 and class names in Chinese

by Philippe Marschall

On 07/29/2010 09:23 AM, Philippe Marschall wrote: > On 07/28/2010 10:48 PM, Alexandre Bergel wrote: >>> I'd even suggest the system to reject names and selectors not in ASCII. >> >> I agree for what has to be put in PharoCore and Pharo. However, a user lambda must be able to create a class called MaClassePrÃ©fÃ©rÃ©e if he/she wishes. Every beginner do this... > > Are you sure all your subsystems (changesets, fileouts, changes file, > Monticello, ...) are Unicode aware? Do you use Unicode normalization? If > so which one? Do you know what the problem is when someone posts a "Invalid utf8 input detected" on this list and how to fix it? Cheers Philippe

July 29, 2010

Re: [Pharo-project] Pharo 1.1/1.2 and class names in Chinese

by Philippe Marschall

On 07/28/2010 10:48 PM, Alexandre Bergel wrote: >> I'd even suggest the system to reject names and selectors not in ASCII. > > I agree for what has to be put in PharoCore and Pharo. However, a user lambda must be able to create a class called MaClassePrÃ©fÃ©rÃ©e if he/she wishes. Every beginner do this... Are you aware that the whole concept of upper and lower case is locale dependent and some languages (Turkish IIRC) have different rules? Cheers Philippe

July 29, 2010

Re: [Pharo-project] Pharo 1.1/1.2 and class names in Chinese

by Philippe Marschall

On 07/28/2010 10:48 PM, Alexandre Bergel wrote: >> I'd even suggest the system to reject names and selectors not in ASCII. > > I agree for what has to be put in PharoCore and Pharo. However, a user lambda must be able to create a class called MaClassePrÃ©fÃ©rÃ©e if he/she wishes. Every beginner do this... Are you sure all your subsystems (changesets, fileouts, changes file, Monticello, ...) are Unicode aware? Do you use Unicode normalization? If so which one? Cheers Philippe

July 29, 2010

Re: [Pharo-project] Pharo 1.1/1.2 and class names in Chinese

by laurent laffont

2010/7/28 Carla F. Griggio <carla.griggio(a)gmail.com> > Well, that last comment reminded me of something: > > I've read code written in english by people that clearly didn't know a lot > of english, and it kept me weeks thinking that the code did something that > it didn't (and, of course, it was more difficult to realize why the code > didn't behave like it was saying :P). > So... as writing everything in english can be a solution, it can be a big > problem too :( And a lot (majority ?) of developpers don't want to use English, or don't understand English, or don't want to try to understand English, or don't have the courage to try to understand English. And they need to communicate their ideas / code with others developpers in the same position :) I don't like writing in French, it's not suitable for programming. Have you ever seen WinDev code with auto-translation ? You end with: i est un entier. x, y sont des entiers. But I think it should be possible to have code in Chinese. Laurent > > > > > On Wed, Jul 28, 2010 at 6:32 PM, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> Once upon a time I wondered if it wouldn't be possible to translate >> the whole sources in any language (via a Dictionary). >> In any other language, we (think of a child) must learn to "talk' to >> computer in computer own language... >> So an apprentice has to learn a new language anyway >> Be it an english computer language is thus not that important. >> However, one of the nice properties of Smalltalk is enabling "talking" >> to the machine in a language close to our natural language, and that >> lowers the barriers. >> So the question of natural language naturally arises. >> >> The translation could be performed statically (transforming a whole >> image)... >> Or tools could as well perform the translation dynamically (using AST)... >> >> In the former case, we must maintain dictionaries if we want to >> continue sharing code with rest of the world. >> In the later case, if user adds a method #foo that already has a >> translation #bar, the effect might be surprising... (where the hell is >> my method foo ?). >> The problem is rather unlikely in English-Chinese conversions though ;) >> >> Untill there is such universal translations available, I agree with Juan: >> in long term, it's better/easier to use a single language wrt >> uniformity/homogeneity. >> I personnally started with franglishe, but tend to use English more and >> more... >> ...well, what I perceive as good English might hurt some ears ;). >> >> Nicolas >> >> 2010/7/28 Alexandre Bergel <alexandre(a)bergel.eu>: >> >> I'd even suggest the system to reject names and selectors not in ASCII. >> > >> > I agree for what has to be put in PharoCore and Pharo. However, a user >> lambda must be able to create a class called MaClassePrÃ©fÃ©rÃ©e if he/she >> wishes. Every beginner do this... >> > >> > Cheers, >> > Alexandre >> > >> > >> >> >> >> Cheers, >> >> Juan Vuletich >> >> >> >> Alexandre Bergel wrote: >> >>> I have no idea how to help you. But trying to have classes with >> chinese (or any other alphabet with accents) names is important. >> >>> Even though I personally write all my code in English, many like to >> write code in their favorite natural language. This is what I see with >> students for example. >> >>> >> >>> Cheers, >> >>> Alexandre >> >>> >> >>> >> >>> On 28 Jul 2010, at 21:33, empty wrote: >> >>> >> >>> >> >>>> In 1.1 and 1.2, without setting a language environment for Chinese, I >> am able >> >>>> to use Chinese by setting fonts. It seems to work except for >> accepting a >> >>>> class named in Chinese will end in a ClassBuilder error of 'Class >> names must >> >>>> be capitalized'. Well is it a feature(requires language environment >> being >> >>>> set correctly) or bug? >> >>>> >> >>>> The code located being: >> >>>> >> >>>> validateClassName: aString >> >>>> "Validate the new class name" >> >>>> >> >>>> aString isSymbol >> >>>> ifFalse: [ ^ false ]. >> >>>> aString first canBeGlobalVarInitial ifFalse:[ >> >>>> self error: 'Class names must be capitalized'. >> >>>> ^false]. >> >>>> environ at: aString ifPresent:[:old| >> >>>> (old isKindOf: Behavior) ifFalse:[ >> >>>> self notify: aString asText allBold, >> ' already exists!\Proceed will store over >> it.' withCRs]]. >> >>>> ^ true >> >>>> >> >>>> and following the code the problemic method is >> #canBeGlobalVarInitial: which >> >>>> is found in two classes: >> >>>> in EncodedCharSet class side: >> >>>> canBeGlobalVarInitial: char >> >>>> >> >>>> | leadingChar | >> >>>> leadingChar := char leadingChar. >> >>>> >> >>>> leadingChar = 0 ifTrue: [^ self isUppercase: char]. >> >>>> ^ self isLetter: char. >> >>>> >> >>>> and in LanguageEnvironment >> >>>> >> >>>> canBeGlobalVarInitial: char >> >>>> >> >>>> ^ Unicode canBeGlobalVarInitial: char. >> >>>> >> >>>> I didn't set a Chinese environment and the exception is occured in in >> >>>> EncodedCharSet class since leadingChar is 0 and a Chinese char seems >> thought >> >>>> to be lowercased. >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> ----- >> >>>> åç¡ä½ åç¡æ³ åç¡å§ >> >>>> -- >> >>>> View this message in context: >> http://forum.world.st/Pharo-1-1-1-2-and-class-names-in-Chinese-tp2305496p23… >> >>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >>>> >> >>>> _______________________________________________ >> >>>> Pharo-project mailing list >> >>>> Pharo-project(a)lists.gforge.inria.fr >> >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >>>> >> >>> >> >>> >> ------------------------------------------------------------------------ >> >>> >> >>> >> >>> No virus found in this incoming message. >> >>> Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: >> 271.1.1/3030 - Release Date: 07/26/10 15:34:00 >> >>> >> >>> >> >> >> >> >> >> _______________________________________________ >> >> 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 >> >> _______________________________________________ >> 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 >

July 29, 2010

Re: [Pharo-project] help with Glamour

by Tudor Girba

Hi Felipe, The result of opening a browser is a window. So, you could use something like this: browser := GLMTabulator new. ... window := browser openOn: ... window maximize. ... window delete. Could I ask in what context you are using Glamour? Also, a better forum for discussing these issues is the moose-dev mailing list: - address: moose-dev(a)iam.unibe.ch - registration: https://www.iam.unibe.ch/mailman/listinfo/moose-dev Cheers, Doru On 28 Jul 2010, at 21:04, Alexandre Bergel wrote: > Hi Felipe, > > No idea, but this is good to see you here! > > Alexandre > > > On 28 Jul 2010, at 18:47, Felipe Ignacio Valverde Campos wrote: > >> Hi, i'm beginner on this tools, so i need your help please :) >> i have some doubts about Glamour, specificaly with GLMTabulator. >> >> how can i set the window size ? >> and how can i close it without pressing the X ? >> >> thanks >> -- >> http://www.dcc.uchile.cl/~fvalverd/public_key.asc >> Estudiante de IngenierÃa Civil en ComputaciÃ³n. >> Facultad de Ciencias FÃsicas y MatemÃ¡ticas. >> Universidad de Chile. >> _______________________________________________ >> 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 -- www.tudorgirba.com "Reasonable is what we are accustomed with."

July 29, 2010

Re: [Pharo-project] Books for summer (was: Time Machine)

by laurent laffont

On Wed, Jul 28, 2010 at 11:45 PM, <csrabak(a)bol.com.br> wrote: > Em 26/07/2010 02:39, laurent laffont < laurent.laffont(a)gmail.com > > escreveu: > > > > And you dear Pharoers, what will you read this summer regarding > > your computing/business activity ? > > > Laurent, > > I'll wait until summer arrives then I'll report back ;-P > :D Should I change the subject to "Books for winter ?" Laurent > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 29, 2010

[Pharo-project] Magma on 1.1 one click image

by Ramiro Diaz Trepat

Hi fellow pharoers, Magma fails to load from the commands on the Pharo 1.1 workspace. In my oppinion they should be removed from the that workspace, it gives users a sloppy impression of the release. I don't think the image has to be sacred and untouched, we can remove 5 lines from a workspace, it will be good for Pharo 1.1. Aside from that minor detail, I am enormously happy and grateful to all for this release. Cheers r

July 28, 2010

Re: [Pharo-project] Books for summer (was: Time Machine)

by csrabak＠bol.com.br

Em 26/07/2010 02:39, laurent laffont < laurent.laffont(a)gmail.com > escreveu: > And you dear Pharoers, what will you read this summer regarding > your computing/business activity ? > Laurent, I'll wait until summer arrives then I'll report back ;-P

July 28, 2010

Re: [Pharo-project] Pharo 1.1/1.2 and class names in Chinese

by Carla F. Griggio

Well, that last comment reminded me of something: I've read code written in english by people that clearly didn't know a lot of english, and it kept me weeks thinking that the code did something that it didn't (and, of course, it was more difficult to realize why the code didn't behave like it was saying :P). So... as writing everything in english can be a solution, it can be a big problem too :( On Wed, Jul 28, 2010 at 6:32 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > Once upon a time I wondered if it wouldn't be possible to translate > the whole sources in any language (via a Dictionary). > In any other language, we (think of a child) must learn to "talk' to > computer in computer own language... > So an apprentice has to learn a new language anyway > Be it an english computer language is thus not that important. > However, one of the nice properties of Smalltalk is enabling "talking" > to the machine in a language close to our natural language, and that > lowers the barriers. > So the question of natural language naturally arises. > > The translation could be performed statically (transforming a whole > image)... > Or tools could as well perform the translation dynamically (using AST)... > > In the former case, we must maintain dictionaries if we want to > continue sharing code with rest of the world. > In the later case, if user adds a method #foo that already has a > translation #bar, the effect might be surprising... (where the hell is > my method foo ?). > The problem is rather unlikely in English-Chinese conversions though ;) > > Untill there is such universal translations available, I agree with Juan: > in long term, it's better/easier to use a single language wrt > uniformity/homogeneity. > I personnally started with franglishe, but tend to use English more and > more... > ...well, what I perceive as good English might hurt some ears ;). > > Nicolas > > 2010/7/28 Alexandre Bergel <alexandre(a)bergel.eu>: > >> I'd even suggest the system to reject names and selectors not in ASCII. > > > > I agree for what has to be put in PharoCore and Pharo. However, a user > lambda must be able to create a class called MaClassePrÃ©fÃ©rÃ©e if he/she > wishes. Every beginner do this... > > > > Cheers, > > Alexandre > > > > > >> > >> Cheers, > >> Juan Vuletich > >> > >> Alexandre Bergel wrote: > >>> I have no idea how to help you. But trying to have classes with chinese > (or any other alphabet with accents) names is important. > >>> Even though I personally write all my code in English, many like to > write code in their favorite natural language. This is what I see with > students for example. > >>> > >>> Cheers, > >>> Alexandre > >>> > >>> > >>> On 28 Jul 2010, at 21:33, empty wrote: > >>> > >>> > >>>> In 1.1 and 1.2, without setting a language environment for Chinese, I > am able > >>>> to use Chinese by setting fonts. It seems to work except for accepting > a > >>>> class named in Chinese will end in a ClassBuilder error of 'Class > names must > >>>> be capitalized'. Well is it a feature(requires language environment > being > >>>> set correctly) or bug? > >>>> > >>>> The code located being: > >>>> > >>>> validateClassName: aString > >>>> "Validate the new class name" > >>>> > >>>> aString isSymbol > >>>> ifFalse: [ ^ false ]. > >>>> aString first canBeGlobalVarInitial ifFalse:[ > >>>> self error: 'Class names must be capitalized'. > >>>> ^false]. > >>>> environ at: aString ifPresent:[:old| > >>>> (old isKindOf: Behavior) ifFalse:[ > >>>> self notify: aString asText allBold, > ' already exists!\Proceed will store over it.' > withCRs]]. > >>>> ^ true > >>>> > >>>> and following the code the problemic method is #canBeGlobalVarInitial: > which > >>>> is found in two classes: > >>>> in EncodedCharSet class side: > >>>> canBeGlobalVarInitial: char > >>>> > >>>> | leadingChar | > >>>> leadingChar := char leadingChar. > >>>> > >>>> leadingChar = 0 ifTrue: [^ self isUppercase: char]. > >>>> ^ self isLetter: char. > >>>> > >>>> and in LanguageEnvironment > >>>> > >>>> canBeGlobalVarInitial: char > >>>> > >>>> ^ Unicode canBeGlobalVarInitial: char. > >>>> > >>>> I didn't set a Chinese environment and the exception is occured in in > >>>> EncodedCharSet class since leadingChar is 0 and a Chinese char seems > thought > >>>> to be lowercased. > >>>> > >>>> > >>>> > >>>> > >>>> ----- > >>>> åç¡ä½ åç¡æ³ åç¡å§ > >>>> -- > >>>> View this message in context: > http://forum.world.st/Pharo-1-1-1-2-and-class-names-in-Chinese-tp2305496p23… > >>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >>>> > >>>> _______________________________________________ > >>>> Pharo-project mailing list > >>>> Pharo-project(a)lists.gforge.inria.fr > >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>>> > >>> > >>> > ------------------------------------------------------------------------ > >>> > >>> > >>> No virus found in this incoming message. > >>> Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: > 271.1.1/3030 - Release Date: 07/26/10 15:34:00 > >>> > >>> > >> > >> > >> _______________________________________________ > >> 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 28, 2010

Re: [Pharo-project] Pharo 1.1/1.2 and class names in Chinese

by Nicolas Cellier

2010/7/28 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > Once upon a time I wondered if it wouldn't be possible to translate > the whole sources in any language (via a Dictionary). > In any other language, we Â (think of a child) must learn to "talk' to > computer in computer own language... > So an apprentice has to learn a new language anyway > Be it an english computer language is thus not that important. > However, one of the nice properties of Smalltalk is enabling "talking" > to the machine in a language close to our natural language, and that > lowers the barriers. > So the question of natural language naturally arises. > > The translation could be performed statically (transforming a whole image)... > Or tools could as well perform the translation dynamically (using AST)... > > In the former case, we must maintain dictionaries if we want to > continue sharing code with rest of the world. > In the later case, if user adds a method #foo that already has a > translation #bar, the effect might be surprising... (where the hell is > my method foo ?). > The problem is rather unlikely in English-Chinese conversions though ;) > > Untill there is such universal translations available, I agree with Juan: One thing I forgot to notice : who never been upset by Excel translations of functions ? > in long term, it's better/easier to use a single language wrt > uniformity/homogeneity. > I personnally started with franglishe, but tend to use English more and more... > ...well, what I perceive as good English might hurt some ears ;). > > Nicolas > > 2010/7/28 Alexandre Bergel <alexandre(a)bergel.eu>: >>> I'd even suggest the system to reject names and selectors not in ASCII. >> >> I agree for what has to be put in PharoCore and Pharo. However, a user lambda must be able to create a class called MaClassePrÃ©fÃ©rÃ©e if he/she wishes. Every beginner do this... >> >> Cheers, >> Alexandre >> >> >>> >>> Cheers, >>> Juan Vuletich >>> >>> Alexandre Bergel wrote: >>>> I have no idea how to help you. But trying to have classes with chinese (or any other alphabet with accents) names is important. >>>> Even though I personally write all my code in English, many like to write code in their favorite natural language. This is what I see with students for example. >>>> >>>> Cheers, >>>> Alexandre >>>> >>>> >>>> On 28 Jul 2010, at 21:33, empty wrote: >>>> >>>> >>>>> In 1.1 and 1.2, without setting a language environment for Chinese, I am able >>>>> to use Chinese by setting fonts. It seems to work except for accepting a >>>>> class named in Chinese will end in a ClassBuilder error of 'Class names must >>>>> be capitalized'. Well is it a feature(requires language environment being >>>>> set correctly) or bug? >>>>> >>>>> The code located being: >>>>> >>>>> validateClassName: aString >>>>> Â Â "Validate the new class name" >>>>> >>>>> Â Â aString isSymbol >>>>> Â Â Â Â Â Â ifFalse: [ ^ false ]. >>>>> Â Â aString first canBeGlobalVarInitial ifFalse:[ >>>>> Â Â Â Â Â Â self error: 'Class names must be capitalized'. >>>>> Â Â Â Â Â Â ^false]. >>>>> Â Â environ at: aString ifPresent:[:old| >>>>> Â Â Â Â Â Â (old isKindOf: Behavior) ifFalse:[ >>>>> Â Â Â Â Â Â Â Â Â Â self notify: aString asText allBold, Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ' already exists!\Proceed will store over it.' withCRs]]. >>>>> Â Â ^ true >>>>> >>>>> and following the code the problemic method is #canBeGlobalVarInitial: which >>>>> is found in two classes: >>>>> in EncodedCharSet class side: >>>>> canBeGlobalVarInitial: char >>>>> >>>>> Â Â | leadingChar | >>>>> Â Â leadingChar := char leadingChar. >>>>> >>>>> Â Â leadingChar = 0 ifTrue: [^ self isUppercase: char]. >>>>> Â Â ^ self isLetter: char. >>>>> >>>>> and in LanguageEnvironment >>>>> >>>>> canBeGlobalVarInitial: char >>>>> >>>>> Â Â ^ Unicode canBeGlobalVarInitial: char. >>>>> >>>>> I didn't set a Chinese environment and the exception is occured in in >>>>> EncodedCharSet class since leadingChar is 0 and a Chinese char seems thought >>>>> to be lowercased. >>>>> >>>>> >>>>> >>>>> >>>>> ----- >>>>> åç¡ä½ åç¡æ³ åç¡å§ >>>>> -- >>>>> View this message in context: http://forum.world.st/Pharo-1-1-1-2-and-class-names-in-Chinese-tp2305496p23… >>>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> Â ------------------------------------------------------------------------ >>>> >>>> >>>> No virus found in this incoming message. >>>> Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: 271.1.1/3030 - Release Date: 07/26/10 15:34:00 >>>> >>>> >>> >>> >>> _______________________________________________ >>> 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 >

July 28, 2010

Re: [Pharo-project] Pharo 1.1/1.2 and class names in Chinese

by Nicolas Cellier

Once upon a time I wondered if it wouldn't be possible to translate the whole sources in any language (via a Dictionary). In any other language, we (think of a child) must learn to "talk' to computer in computer own language... So an apprentice has to learn a new language anyway Be it an english computer language is thus not that important. However, one of the nice properties of Smalltalk is enabling "talking" to the machine in a language close to our natural language, and that lowers the barriers. So the question of natural language naturally arises. The translation could be performed statically (transforming a whole image)... Or tools could as well perform the translation dynamically (using AST)... In the former case, we must maintain dictionaries if we want to continue sharing code with rest of the world. In the later case, if user adds a method #foo that already has a translation #bar, the effect might be surprising... (where the hell is my method foo ?). The problem is rather unlikely in English-Chinese conversions though ;) Untill there is such universal translations available, I agree with Juan: in long term, it's better/easier to use a single language wrt uniformity/homogeneity. I personnally started with franglishe, but tend to use English more and more... ...well, what I perceive as good English might hurt some ears ;). Nicolas 2010/7/28 Alexandre Bergel <alexandre(a)bergel.eu>: >> I'd even suggest the system to reject names and selectors not in ASCII. > > I agree for what has to be put in PharoCore and Pharo. However, a user lambda must be able to create a class called MaClassePrÃ©fÃ©rÃ©e if he/she wishes. Every beginner do this... > > Cheers, > Alexandre > > >> >> Cheers, >> Juan Vuletich >> >> Alexandre Bergel wrote: >>> I have no idea how to help you. But trying to have classes with chinese (or any other alphabet with accents) names is important. >>> Even though I personally write all my code in English, many like to write code in their favorite natural language. This is what I see with students for example. >>> >>> Cheers, >>> Alexandre >>> >>> >>> On 28 Jul 2010, at 21:33, empty wrote: >>> >>> >>>> In 1.1 and 1.2, without setting a language environment for Chinese, I am able >>>> to use Chinese by setting fonts. It seems to work except for accepting a >>>> class named in Chinese will end in a ClassBuilder error of 'Class names must >>>> be capitalized'. Well is it a feature(requires language environment being >>>> set correctly) or bug? >>>> >>>> The code located being: >>>> >>>> validateClassName: aString >>>> Â Â "Validate the new class name" >>>> >>>> Â Â aString isSymbol >>>> Â Â Â Â Â Â ifFalse: [ ^ false ]. >>>> Â Â aString first canBeGlobalVarInitial ifFalse:[ >>>> Â Â Â Â Â Â self error: 'Class names must be capitalized'. >>>> Â Â Â Â Â Â ^false]. >>>> Â Â environ at: aString ifPresent:[:old| >>>> Â Â Â Â Â Â (old isKindOf: Behavior) ifFalse:[ >>>> Â Â Â Â Â Â Â Â Â Â self notify: aString asText allBold, Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ' already exists!\Proceed will store over it.' withCRs]]. >>>> Â Â ^ true >>>> >>>> and following the code the problemic method is #canBeGlobalVarInitial: which >>>> is found in two classes: >>>> in EncodedCharSet class side: >>>> canBeGlobalVarInitial: char >>>> >>>> Â Â | leadingChar | >>>> Â Â leadingChar := char leadingChar. >>>> >>>> Â Â leadingChar = 0 ifTrue: [^ self isUppercase: char]. >>>> Â Â ^ self isLetter: char. >>>> >>>> and in LanguageEnvironment >>>> >>>> canBeGlobalVarInitial: char >>>> >>>> Â Â ^ Unicode canBeGlobalVarInitial: char. >>>> >>>> I didn't set a Chinese environment and the exception is occured in in >>>> EncodedCharSet class since leadingChar is 0 and a Chinese char seems thought >>>> to be lowercased. >>>> >>>> >>>> >>>> >>>> ----- >>>> åç¡ä½ åç¡æ³ åç¡å§ >>>> -- >>>> View this message in context: http://forum.world.st/Pharo-1-1-1-2-and-class-names-in-Chinese-tp2305496p23… >>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> Â ------------------------------------------------------------------------ >>> >>> >>> No virus found in this incoming message. >>> Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: 271.1.1/3030 - Release Date: 07/26/10 15:34:00 >>> >>> >> >> >> _______________________________________________ >> 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

July 28, 2010

Re: [Pharo-project] Pharo 1.1/1.2 and class names in Chinese

by Carla F. Griggio

If I'm writing code for a project I mean to share, I write the code in english of course. But at my work, where I have to deal with very specific vocabulary that could be almost ridiculous to translate, I feel more comfortable writing in spanish (my native language) and not forcing the domain to be translated. I don't think it's a beginner's thing, I think it's just confortable for anyone depending on the objective of the project and working context. But yes, I find myself writing ugly selectors like "add*Indice*:" instead of "addIndex:" or "*agregarIndice*:" and stuff like that, but I choose to see "add..." more as a convention instead of another language :P Even if I were writing in english, I'd follow that convention. "*Indice*" means a domain specific concept in my work, and might even be confused with some collection index, for example. Besides all this, it's something that happens not only in Smalltalk but any language I can think about, specially if you use shared libraries or frameworks. The thing here is that Smalltalk classes must begin with capital letters. But what if your language doesn't have capital letters, even more funny, what if it doesn't have any *letters*? XD And thinking about that, here's a newbie and maybe stupid question: why do classes have to begin with a capital letter? Is it a technical issue or just following conventions? If the answer is following conventions*... well... just as I follow the "add" convention, unfortunately I'd suggest following the "classes with capital letters in ASCII" too :( :( *or maybe classes are identified as such by the compiler when they begin with capital letters *because* of the existing convention... Carla On Wed, Jul 28, 2010 at 5:48 PM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > > I'd even suggest the system to reject names and selectors not in ASCII. > > I agree for what has to be put in PharoCore and Pharo. However, a user > lambda must be able to create a class called MaClassePrÃ©fÃ©rÃ©e if he/she > wishes. Every beginner do this... > > Cheers, > Alexandre > > > > > > Cheers, > > Juan Vuletich > > > > Alexandre Bergel wrote: > >> I have no idea how to help you. But trying to have classes with chinese > (or any other alphabet with accents) names is important. > >> Even though I personally write all my code in English, many like to > write code in their favorite natural language. This is what I see with > students for example. > >> > >> Cheers, > >> Alexandre > >> > >> > >> On 28 Jul 2010, at 21:33, empty wrote: > >> > >> > >>> In 1.1 and 1.2, without setting a language environment for Chinese, I > am able > >>> to use Chinese by setting fonts. It seems to work except for accepting > a > >>> class named in Chinese will end in a ClassBuilder error of 'Class names > must > >>> be capitalized'. Well is it a feature(requires language environment > being > >>> set correctly) or bug? > >>> > >>> The code located being: > >>> > >>> validateClassName: aString > >>> "Validate the new class name" > >>> > >>> aString isSymbol > >>> ifFalse: [ ^ false ]. > >>> aString first canBeGlobalVarInitial ifFalse:[ > >>> self error: 'Class names must be capitalized'. > >>> ^false]. > >>> environ at: aString ifPresent:[:old| > >>> (old isKindOf: Behavior) ifFalse:[ > >>> self notify: aString asText allBold, > ' already exists!\Proceed will store over it.' > withCRs]]. > >>> ^ true > >>> > >>> and following the code the problemic method is #canBeGlobalVarInitial: > which > >>> is found in two classes: > >>> in EncodedCharSet class side: > >>> canBeGlobalVarInitial: char > >>> > >>> | leadingChar | > >>> leadingChar := char leadingChar. > >>> > >>> leadingChar = 0 ifTrue: [^ self isUppercase: char]. > >>> ^ self isLetter: char. > >>> > >>> and in LanguageEnvironment > >>> > >>> canBeGlobalVarInitial: char > >>> > >>> ^ Unicode canBeGlobalVarInitial: char. > >>> > >>> I didn't set a Chinese environment and the exception is occured in in > >>> EncodedCharSet class since leadingChar is 0 and a Chinese char seems > thought > >>> to be lowercased. > >>> > >>> > >>> > >>> > >>> ----- > >>> åç¡ä½ åç¡æ³ åç¡å§ > >>> -- > >>> View this message in context: > http://forum.world.st/Pharo-1-1-1-2-and-class-names-in-Chinese-tp2305496p23… > >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >>> > >>> _______________________________________________ > >>> Pharo-project mailing list > >>> Pharo-project(a)lists.gforge.inria.fr > >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>> > >> > >> > ------------------------------------------------------------------------ > >> > >> > >> No virus found in this incoming message. > >> Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: > 271.1.1/3030 - Release Date: 07/26/10 15:34:00 > >> > >> > > > > > > _______________________________________________ > > 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 >

July 28, 2010

[Pharo-project] Aida/Web now loads and runs well on Pharo 1.1

by Janko MivÅ¡ek

Hi guys, I just made Aida ready on new and wonderfull Pharo 1.1. and now Aida installs and run nicelly and even side by side with Seaside. You can even run both on the same Swazoo web server, which is also included. Just evulate DEVImageWorkspaces openExternalProjectWorkspace then evaluate loads of both Seaside and Aida, then start both, for Aida evaluate: SwazooAida demoStart "open http://localhost:8888 in your web browser" Best regards Janko -- Janko MivÅ¡ek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si

July 28, 2010