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

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