- Pharo-dev - lists.pharo.org

Re: [Pharo-project] TORCH: supporting source-code change integration

by Veronica Isabel Uquillas Gomez

Hola Mariano, Yup, I considered that but as there are already many buttons, I never tried.. Will try it anyway... gracias, Veronica On 18 May 2010, at 12:12, Mariano Martinez Peck wrote: > Hola VerÃ³nica! > > I love it!!! nice, very nice :) > > I will give you more feedback as far as I start to use it. > The only thing I would add is a button in the MC. Look the attached screenshot. It would be cool not only to have it in the context menu, but in the MC broser...for example, next to "changes" button a "torch" button or something like that. > > I really like it. Moose and all it tools seems to be working in Pharo 1.1 so....maybe if people agree we can include this cool tool together with Mondrian and Glamour ? They have 460 green tests :) > > DEV!!!!!!!! > > :) > > On Tue, May 18, 2010 at 11:39 AM, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Hi Veronica, > > It is pretty impressive :). > > Would it be Ok if I added this on the Moose page? > > Cheers, > Doru > > > > On 18 May 2010, at 11:21, StÃ©phane Ducasse wrote: > > Thanks veronica. > lukas said that he was impressed this is a complement :) > > On May 18, 2010, at 11:00 AM, Veronica Isabel Uquillas Gomez wrote: > > Dear all, > > I would like to announce Torch, a tool for supporting source-code change integration. For now, it offers visualizations of the changes and enhanced change lists. > Torch can be accessed through Monticello (in the main MC browser, in the repository browser or in the history browser). Selecting a version or slice, you can view the changes with Torch using the contextual menu. > Once you open the Torch dashboard, you can access the enhanced change list or a detailed visualization via the contextual menu as well. > > Torch is available on SqueakSource, the repository is named Torch, and you need to load the ConfigurationOfTorch package. > It runs in a dev or core image. > > For a dev image. > - ConfigurationOfTorch loadVersion10 > > For a core image. > 1) Set fonts - described in the attached file. > 2) ConfigurationOfTorch loadDefault > > I would appreciate comments and feedback! > > Best Regards, > VerÃ³nica Uquillas GÃ³mez > Vrije University Brussel - SOFT Lab > University of Lille - RMOD Team > > <torchFontsScript.st> > > > > _______________________________________________ > 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 > > -- > www.tudorgirba.com > > "Problem solving efficiency grows with the abstractness level of problem understanding." > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > <Picture 5.png>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 19, 2010

Re: [Pharo-project] TORCH: supporting source-code change integration

by Veronica Isabel Uquillas Gomez

Hi Henry Indeed you are right, and that prerequisite is the only one which is overriding code... I was doing some tests, and I think I can remove it for a core image configuration, will discuss with Tudor regards, Veronica On 18 May 2010, at 14:58, Henrik Johansen wrote: > In particular, this prereq in ConfigurationOfGlamour caused it: > baseline20beta4: spec > spec for: #common do: [ > *snip* > spec package: 'Morphic-MorphTreeWidget' with: [ > spec repository: 'http://squeaksource.com/Momo10']; > *snip* > ] > > As I said, since MorphTreeWidget is already part of 1.1Core, this caused an older version of the widget to load. > > Since Settings Browser uses methods found in the newer version in Core, loading Glamour caused it to DNU when I tried opening a Settings Browser. > > Cheers, > Henry > > > On May 18, 2010, at 2:41 15PM, Henrik Johansen wrote: > >> Yes, that is where it broke.... >> >> >> On May 18, 2010, at 2:32 30PM, StÃ©phane Ducasse wrote: >> >>> henrik >>> >>> did you try on 1.1? >>> >>> Stef >>> >>> On May 18, 2010, at 1:00 PM, Henrik Johansen wrote: >>> >>>> >>>> >>>> Den 18.05.2010 12:12, skrev Mariano Martinez Peck: >>>>> Hola VerÃ³nica! >>>>> >>>>> I love it!!! nice, very nice :) >>>>> >>>>> I will give you more feedback as far as I start to use it. >>>>> The only thing I would add is a button in the MC. Look the attached >>>>> screenshot. It would be cool not only to have it in the context menu, >>>>> but in the MC broser...for example, next to "changes" button a "torch" >>>>> button or something like that. >>>>> >>>>> I really like it. Moose and all it tools seems to be working in Pharo >>>>> 1.1 so....maybe if people agree we can include this cool tool together >>>>> with Mondrian and Glamour ? They have 460 green tests :) >>>> Strange, for me it lead to errors in 1.1 because: >>>> - It depends on Momo10 (MorphTreeMorph) >>>> - This has been integrated into Morphic in 1.1 >>>> - Loading Torch overrode the code in Morphic with code from Momo rep. >>>> - The "old" tree was missing methods (rowInset:) used by the settings >>>> browser, so that broke. >>>> >>>> Soooo, Metacello tags with version info as well coming soon? >>>> I really haven't followed that discussion :) >>>> >>>> Cheers, >>>> Henry >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 19, 2010

Re: [Pharo-project] Managing Pharo external packages with Metacello, please read!

by StÃ©phane Ducasse

sound cool. Estenban we need more :) On May 19, 2010, at 2:45 AM, Dale Henrichs wrote: > Yes, I don't think that it is a good idea to modify the configuration when it is published in the PharoXXMetacelloRepository. > > In the end the reason for this discussion revolves around the desire to provide a simple method for developers/users to load projects that are "known/tested to work in PharoXX". > > Creating a PharoXXMetacelloRepository means that we have a "white list" of configurations that are"known/tested to work in PharoXX". > > GoferProjectLoader provides an API for loading projects from a target repository. The API makes it very simple to load a particular project by name, without having to specify more details about the version of groups involved. It also means that one can arrange to do special things under the cover of the GoferProjectLoader, like point to a different repository based upon the version of Pharo that it is running in ... > > I think that what we need in addition to a "white list" of projects, a "white list" of _versions_ that are "known/tested to work in PharoXX." > > I think it would be straightforward to subclass/extend the GoferProjectLoader to add the notion of a version/group "white list" that records the exact configuration/version/group(s) that have been tested and known to work. This same extension to GoferProjectLoader can automatically include an overrideRepositories: to ensure that all projects/packages are loaded from the PharoXXMetacelloRepository repository... > > By default, the GoferProjectLoader loaded into PharoXX would point to PharoXXMetacelloRepository and use the "white list" of versions. > > Once a developer/user has become comfortable using PharoXX, he/she can configure GoferProjectLoader to suit his/her needs as well as directly load Configurations/versions that are not on the "white list" (using Metacello directly) without requiring any changes to the configurations or where they originated from... > > So in the end the following expression will do things differently depending upon a) which version of Pharo it is executed in and b) whether or not you are using the 'default' GoferProjectLoader: > > Gofer project load: 'SqueakDBX'. > > All while using the same Configuration... > > Dale > > StÃ©phane Ducasse wrote: >> Yes I think that this is what dale proposed. >> Dale is off line today but he will probably comment >> Stef >> >> On May 18, 2010, at 10:59 AM, Tudor Girba wrote: >> >> >> >>> Hi, >>> >>> I like this approach: >>> 1. Projects can continue to be built independently. For example, in Moose, we have already a process with multiple configurations (one for each repository) depending on each other. >>> 2. When ready, the Configurations and all related packages are "published" in the PharoXXMetacelloRepository. Having a package per Configuration makes it easy to copy it. >>> >>> The only problem is that the code of Configuration mentions explicitly the repository (especially in the case of having nested Configurations, I point to a configuration by specifying the repository, package, and class). So, I guess the simplest thing here would be to provide the default "load" method to already override dynamically all repositories with the PharoXXMetacelloRepository. >>> >>> Cheers, >>> Doru >>> >>> >>> On 18 May 2010, at 09:32, StÃ©phane Ducasse wrote: >>> >>> >>> >>>> I understand nicolas. Now my agenda is more than full. >>>> and the proposal is here. Simple >>>> >>>> ========================================================== >>>> One repo per version Pharo1.0, Pharo11 ... MetacelloRepository >>>> containing **published** configurationOfXXX >>>> -> all the dependent packages are copied locally + configuration ready to load using load. >>>> >>>> A project >>>> contain its single/or several configurationOfMyProject with the complete history >>>> people commit the config to their repository and if they want they **publish** from their repository to the version repository >>>> a version. This version is frozen -> all the dependent packages are copied locally + configuration ready to load using load. >>>> >>>> For Pharo core or pharo packages that we maintain we want to maintain it as a project. >>>> with its own repository and packages. >>>> >>>> We can use automatic build server to validate the status or migration between different repositories >>>> ========================================================== >>>> >>>> >>>> Stef >>>> >>>> On May 17, 2010, at 11:00 PM, Nicolas Cellier wrote: >>>> >>>> >>>> >>>>> The meaning of my message was don't do it for squeak, but do it for yourself. >>>>> I don't doubt the mailing list is a mine of information, but even in >>>>> the best mine you need to dig a lot before extracting the gold >>>>> nuggets. >>>>> Of course, I've got no right to control your agenda, who am I ? >>>>> You can consider the subject close, and I won't find your attitude >>>>> shocking at all. >>>>> But next time, consider writing a rationale for your own, it will >>>>> increase quality of Pharo decision process. >>>>> >>>>> Best regards >>>>> >>>>> Nicolas >>>>> >>>>> 2010/5/17 StÃ©phane Ducasse >>>>> <stephane.ducasse(a)inria.fr> >>>>> : >>>>> >>>>> >>>>>> nicolas >>>>>> >>>>>> all the information is in the metacello mailing-list and we already posted many mails on that topics in this mailing list. >>>>>> I'm sorry but I do not have the time to repeat again what we said. Now since I'm in a really good mood >>>>>> in a nutshell >>>>>> >>>>>> one repo per version Pharo1.0, Pharo11 ... MetacelloRepository >>>>>> containing configurationOfXXX frozen = all the dependent packages are copied locally + configuration ready to load using load. >>>>>> >>>>>> a project >>>>>> contain its single/or whatever configurationOfMyProject >>>>>> people publish the config to their repository and if they want they push from their repository to the version repository >>>>>> a version that they freeze (may be using tags) >>>>>> >>>>>> For Pharo core or pharo packages that we maintain we want to maintain it as a project. >>>>>> with its own repository and packages. >>>>>> >>>>>> Then we have a server that load configuration and barks if something wrong happen. And may be we kick out >>>>>> the configurationofXXX from MetacelloRepositories >>>>>> >>>>>> >>>>>> >>>>>>> Steph, >>>>>>> I understand how boring it may seem: >>>>>>> - you already discussed the subject over and over >>>>>>> - you already took decisions >>>>>>> and now we come later with new proposals, and ask you to reconsider >>>>>>> the work again... >>>>>>> >>>>>>> >>>>>> more than that. :) >>>>>> It looks like if we did not talk or think about what we are doing. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> As for the Preferences/Settings, Pharo choices are probably very weel thought. >>>>>>> >>>>>>> However, every solution will come with trade offs, and it would be >>>>>>> good to have a rationale justifying the choices you made, and perhaps >>>>>>> more importantly justifying why you did abandon some solutions, >>>>>>> because some questions might be repeated in Pharo 1.2, 1.3, 2.0 ... >>>>>>> and find different answers in different context. Note that Squeak >>>>>>> evolutions might have influence on Pharo too, and it's part of the >>>>>>> context... >>>>>>> >>>>>>> I strongly encourage you to establish your rationale on Pharo grounds >>>>>>> - independently of Andreas proposals, put it on the Pharo wiki and let >>>>>>> us know the URL. >>>>>>> >>>>>>> You also know that Squeak goals are not exactly those of Pharo w.r.t. >>>>>>> backward compatibility, so Squeak can't just blindly replicate Pharo >>>>>>> solutions without a rationale. >>>>>>> >>>>>>> The merit of Andreas proposal is to try and establish such a >>>>>>> rationale. Without it, we're bound to repeat discussions again and >>>>>>> again, >>>>>>> >>>>>>> >>>>>> So to fix the problem consider that as our proposal. >>>>>> >>>>>> Stef >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>>> >>>> >>> -- >>> >>> www.tudorgirba.com >>> >>> >>> "Every thing has its own flow." >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> >> >> >> >

May 19, 2010

Re: [Pharo-project] TORCH: supporting source-code change integration

by StÃ©phane Ducasse

On May 19, 2010, at 12:47 AM, Tudor Girba wrote: > Hi Veronica, > > A bit of feedback: > - After loading Torch, the package contextual menu seems to crash the Monticello Browser > - You extend isSuper in RBProgramNode and RBVariableNode, which generates an override conflict with methods in Moose-Core. may be moose should have a look at the new AST-semantics package that lukas created because veronica used that ones originally and after a discussing with lukas he created ast-semantics > - The Glamour tags look different, so I guess you also have some Glamour overrides. That should not happen :). Maybe you have some suggestions for improvement, or maybe you just need the border for the [i] icon? > > Cheers, > Doru > > > On 18 May 2010, at 15:16, Veronica Isabel Uquillas Gomez wrote: > >> Hi Tudor, >> >> thank you :D >> >> sure!!! >> >> cheers, >> Veronica >> >> >> On 18 May 2010, at 11:39, Tudor Girba wrote: >> >>> Hi Veronica, >>> >>> It is pretty impressive :). >>> >>> Would it be Ok if I added this on the Moose page? >>> >>> Cheers, >>> Doru >>> >>> >>> On 18 May 2010, at 11:21, StÃ©phane Ducasse wrote: >>> >>>> Thanks veronica. >>>> lukas said that he was impressed this is a complement :) >>>> >>>> On May 18, 2010, at 11:00 AM, Veronica Isabel Uquillas Gomez wrote: >>>> >>>>> Dear all, >>>>> >>>>> I would like to announce Torch, a tool for supporting source-code change integration. For now, it offers visualizations of the changes and enhanced change lists. >>>>> Torch can be accessed through Monticello (in the main MC browser, in the repository browser or in the history browser). Selecting a version or slice, you can view the changes with Torch using the contextual menu. >>>>> Once you open the Torch dashboard, you can access the enhanced change list or a detailed visualization via the contextual menu as well. >>>>> >>>>> Torch is available on SqueakSource, the repository is named Torch, and you need to load the ConfigurationOfTorch package. >>>>> It runs in a dev or core image. >>>>> >>>>> For a dev image. >>>>> - ConfigurationOfTorch loadVersion10 >>>>> >>>>> For a core image. >>>>> 1) Set fonts - described in the attached file. >>>>> 2) ConfigurationOfTorch loadDefault >>>>> >>>>> I would appreciate comments and feedback! >>>>> >>>>> Best Regards, >>>>> VerÃ³nica Uquillas GÃ³mez >>>>> Vrije University Brussel - SOFT Lab >>>>> University of Lille - RMOD Team >>>>> >>>>> <torchFontsScript.st> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> -- >>> www.tudorgirba.com >>> >>> "Problem solving efficiency grows with the abstractness level of problem understanding." >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > > -- > www.tudorgirba.com > > "Problem solving efficiency grows with the abstractness level of problem understanding." > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 19, 2010

Re: [Pharo-project] [Moose-dev] rome

by StÃ©phane Ducasse

On May 19, 2010, at 12:08 AM, Schwab,Wilhelm K wrote: > Stef, > > Thanks, that helps. Where does post script fit into it? I am getting a few steps ahead of myself here, but some day it would be important to be able to print on Linux. Sooner than that, it would be nice to do something similar to passing a Windows HDC into a function in a DLL to speed up loops over lots of numbers. If nothing else, the primitives should serve as examples for anything I find missing. it could fit in there. Rome is an API. so we can after have the subclasses we would like draw on various canvases. > > One small frustration/irony has been that I now end up using code to turn what should be double arrays into ordinary collections of objects then into text to shove into gnuplot. There are some hints that I might be able to do better, but for now, the graphics from gnuplot are worth looking the other way :) > > Bill > > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse > Sent: Tuesday, May 18, 2010 4:22 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] [Moose-dev] rome > > rome is a new api for rendering image and text. > the idea is to offer a common api and several backends > one would balloon > another would be cairo/pango > a third one could be morphic30 primitives > > the idea is to get rome working with the vm primitives and/or balloon then to get it working with cairo via the ROME plugin > > then we could start to migrate the system to use this api. > > Stef > > > On May 18, 2010, at 11:14 PM, Schwab,Wilhelm K wrote: > >> Having some code to load will go a long way to answering my question, but more basic than that, I have tried (and failed miserably) to trace Rome back to some library/framework/etc. Is there any background reading I can do to see where this might be heading? Any pointers would be greatly appreciated. >> >> Bill >> >> >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of >> Cyrille Delaunay >> Sent: Tuesday, May 18, 2010 4:04 AM >> To: Related to the development of Moose and other related tools >> Cc: pharo-project >> Subject: Re: [Pharo-project] [Moose-dev] rome >> >> Hello, >> >> Indeed, I started to build a small package, integrating one by one things working in Rome. >> You can load it from the squeak source repository: >> www.squeaksource.com/Athens >> >> For now, the working canvas are: >> - RomePluginCanvas (making the binding with cairo) >> - RomeBalloonCanvas >> >> You can see some examples in the class side of RomeDemo. >> All is not working. You can have a look at RomeDemo >> demoMovingCar, that should work with the RomePluginCanvas and the RomeBalloonCanvas. >> >> All that concern fonts is not yet integrated, a lot of thing are already broken in the sophie dev image. >> So all examples drawing simple form, without text, should work. >> >> You can also have a look at the version of Alain plantec, from which I based the package Athens. This is already a condense version of all stuffs from the sophie image. >> You can load it from: www.squeaksource.source/PharoTaskForces (load te last version of 'Rome'). >> >> The next steps are: >> - Integrate fonts >> - The class RomeSVGDemo doesn't work >> >> >> >> >> 2010/5/17 Tudor Girba <tudor.girba(a)gmail.com> Hi Cyrille, >> >> A bird told me that you are working on a Rome plugin. What is the >> status? Could we test something? :) >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> >> "The coherence of a trip is given by the clearness of the goal." >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> _______________________________________________ >> 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

May 19, 2010

Re: [Pharo-project] Fwd: Re: Decoding bug with XMLParser ?

by StÃ©phane Ducasse

> Another "hard to quote" message, but I hope my answer will be clear. > The "problem" is that in Pharo the leadingChar for unicode characters is still 255. This was changed in Squeak 4.1 to 0. So in Squeak 4.1: > (Unicode value: 8230) codePoint. "===> 8230" > > While in Pharo it's: > (Unicode value: 8230) codePoint. "===> 1069555750" > (Character value: 1069555750) charCode. "===> 8230" > (Character value: 1069555750) leadingChar. "===> 255" > > So using #charCode instead of #codePoint is the solution. Thanks levente. In Pharo 1.1 we get the same as in squeak. > (Unicode value: 8230) codePoint. "===> 1069555750" > (Character value: 1069555750) charCode. "===> 8230" > (Character value: 1069555750) leadingChar. "===> 255" 0 locale encoded by 0 is Unicode initialize self allSubclassesDo: [:each | each initialize]. EncodedCharSets := Array new: 256. EncodedCharSets at: 0+1 put: Unicode "Latin1Environment". EncodedCharSets at: 1+1 put: JISX0208. EncodedCharSets at: 2+1 put: GB2312. EncodedCharSets at: 3+1 put: KSX1001. EncodedCharSets at: 4+1 put: JISX0208. EncodedCharSets at: 5+1 put: JapaneseEnvironment. EncodedCharSets at: 6+1 put: SimplifiedChineseEnvironment. EncodedCharSets at: 7+1 put: KoreanEnvironment. EncodedCharSets at: 8+1 put: GB2312. "EncodedCharSets at: 9+1 put: UnicodeTraditionalChinese." "EncodedCharSets at: 10+1 put: UnicodeVietnamese." EncodedCharSets at: 12+1 put: KSX1001. EncodedCharSets at: 13+1 put: GreekEnvironment. EncodedCharSets at: 14+1 put: Latin2Environment. EncodedCharSets at: 15+1 put: RussianEnvironment. EncodedCharSets at: 16+1 put: NepaleseEnvironment. EncodedCharSets at: 256 put: Unicode. > Now I was wondering why in squeak and pharo (Character value: 1069555750) leadingChar. "===> 255" stef

May 19, 2010

Re: [Pharo-project] Pharo sprint this Saturday

by Serge Stinckwich

On Wed, May 19, 2010 at 6:15 AM, Alexandre Bergel <alexandre.bergel(a)inria.fr> wrote: > Hi All, > > I am now with Mariano, working on the details for this Saturday. > More info on http://code.google.com/p/pharo/wiki/PharoSprints > Please, get in touch with Mariano first if you want to attend. > > As already said, the objective of the sprint will be to help produce Pharo 1.1 > > We will try to be present on IRC and/or iChat for remote pair programming :-) Hi Alex, maybe you could add the GMT time of the sprint if some people want to join. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

May 19, 2010

Re: [Pharo-project] problem with CompiledMethod equality

by StÃ©phane Ducasse

Elliot I think that we already took into changes made by nicolas. Stef On May 19, 2010, at 2:35 AM, Eliot Miranda wrote: > Hi Lukas, > > On Tue, May 18, 2010 at 8:17 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > > Same method in different classes do not equal eachother though, if I've not made a mistake in: > > > > |mrtCp| > > mrtCp := (InstructionClient>>#methodReturnTop) copy. > > mrtCp literalAt: 2 put: #ContextPart->ContextPart. > > (InstructionClient>>#methodReturnTop) = mrtCp > > For methods that send super the behavior changes if you change the > class binding. That's probably why it is not ignored for #=. > > In fact I would suggest to #= from compiled method altogether, in most > cases it doesn't do what one would expect in a given context anyway. > There are too many and possibility completely different > interpretations of #= for CompiledMethod. #== is the only decent > implementation for this class. > > I sympathise but I think there is a reasonable default interpretation of #= for CompiledMethod that is what most people want. The intent is to answer whether two methods have the same execution semantics and same method tags & properties, e.g. if one were to compile the same source code in two different classes that had the same inst var offsets for the inst vars in the methods, then one would want those methods to be #=. This allows tests such as > - checking whether a subclass has a method that is #= to a superclass, and is hence redundant. > - checking whether a set of sourceless methods are equivalent so that they may be shared under different selectors (e.g. think auto-generated accessor methods which can be cached and shared) > So for this informal definition the selector and the class are irrelevant, but bytecodes and literals (apart from the selector and method class literals) are relevant. Its almost a short-cut comparison of error-free decompilation, although there are differences in the bytecode that wouldn't show in decompilation (e.g. using long branches for short branches). > > The current definition serves for compiler hackers as it tells you accurately whether a compiler change has an effect on the bytecode, can be used to test whether compilation followed by decompilation followed by recompilation has an effect, etc. While it may not be a universal code comparison method it has met my needs throughout the closure compiler so at least I'm pretty happy with it. > > (pleading for CompiledMethod>>#= to stay the same as the current Squeak 4.1 definition, which ever since Nichoas Celier's float compilation changes, is pretty darned good). > > best > Eliot > > > > > > Lukas > > > > > At the very least, the branches of > > index = 1 and: [ #(117 120) includes: self primitive ]) > > ifTrue: [ > > > > REALLY deserve some comments... > > > > Cheers, > > Henry > > > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 19, 2010

Re: [Pharo-project] Pharo sprint this Saturday

by StÃ©phane Ducasse

Excellent! Do not forget to ask participants to sign the license agreement. Stef On May 19, 2010, at 1:15 AM, Alexandre Bergel wrote: > Hi All, > > I am now with Mariano, working on the details for this Saturday. > More info on http://code.google.com/p/pharo/wiki/PharoSprints > Please, get in touch with Mariano first if you want to attend. > > As already said, the objective of the sprint will be to help produce Pharo 1.1 > > We will try to be present on IRC and/or iChat for remote pair programming :-) > > Cheers, > Alexandre > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 19, 2010

Re: [Pharo-project] Fwd: Re: Decoding bug with XMLParser ?

by Damien Pollet

2010/5/19 Levente Uzonyi <leves(a)elte.hu>: > Another "hard to quote" message, but I hope my answer will be clear. > The "problem" is that in Pharo the leadingChar for unicode characters is > still 255. This was changed in Squeak 4.1 to 0. So in Squeak 4.1: > (Unicode value: 8230) codePoint. "===> 8230" > > While in Pharo it's: > (Unicode value: 8230) codePoint. "===> 1069555750" > (Character value: 1069555750) charCode. "===> 8230" > (Character value: 1069555750) leadingChar. "===> 255" > > So using #charCode instead of #codePoint is the solution. What about updating the leadingChar in Pharo to match Squeak? (I know it's not the correct solution to the present problem but it's these kinds of sneaky differences between platform that make life difficult) What's the semantic difference between picking 0 or 255? Is one more correct than the other? -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

May 19, 2010