- Pharo-dev - lists.pharo.org

[Pharo-project] Problem with Demo mode [WAS] Re: [BetaTesting] [ANN] Pharo-1.1-11367-Beta1dev10.05.1

by Mariano Martinez Peck

On Mon, May 24, 2010 at 11:56 AM, Serge Stinckwich < serge.stinckwich(a)gmail.com> wrote: > When i switch to demo mode, method selector in System Browser are no > more bold in the bottom pane. > I didn't understand you. Could you please attach both screenshots: how it should be and how is it ? Alain do you know about this ? Cheers > > 2010/5/21 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > Hi Pharaoers. I am pleased to announce the first Pharo 1.1 beta based on > > PharoCore-1.1-11367-Beta. It is the first time we build a Pharo 1.1 dev > > image with PharoCore 1.1 so the image may be not 100% stable. However, we > > think it is good to release it so that people can start to test it, load > > their own packages, adapt them, etc. We would like to receive feedback > about > > it. It (yet) has failing and error tests. > > > > The main changes with Pharo 1.0 is that of course, it is based on a > > PharoCore 1.1 with all that it means. We started to write down some of > the > > actions done in PharoCore 1.1. The list so far can be found here: > > http://code.google.com/p/pharo/wiki/ActionsInPharoOneDotOne > > Of course, for the stable releae of Pharo 1.1 we will do a clear list in > the > > website as we did for 1.0. > > > > Regarding the included packages in 1.1 we added ScriptManager (a tool to > > manage and persist workspaces), ProfStefBrowser, ArchiveViewer, > > MethodWrappers and ObjectMetaTools (which includes things like > > ProtocolCatcher, ObjectTracer, ObjectViewer, etc). > > > > Another difference is the font. In Pharo 1.0 we used TrueType fonts by > > default. In Pharo 1.1 we use StrikeFonts (no need of TrueType plugin, > > netiher to have the fonts). However, of course, you can disable > StrikeFonts > > and put TrueType like in 1.0. > > > > That's all. We would really appreciate you use it, test it, report > issues, > > provide fixes, etc. It is important also that you start to use your own > > packages/applications. There have been several changes in 1.1 that may > > require change in your code. > > > > Ahh if you want to create the image yourself, check as usually the > > installScript.st file to see how to do it. Actually, you can just take a > > PharoCore-1.1-11367-Beta image and evaluate (the same procedure as 1.0): > > > > Gofer new > > squeaksource: 'MetacelloRepository'; > > package: 'ConfigurationOfPharo'; > > load. > > > > ((Smalltalk at: #ConfigurationOfPharo) project version: > '1.1-beta1.10517') > > load. > > > > Here is the link to the image: > > > > > https://gforge.inria.fr/frs/download.php/27025/Pharo-1.1-11367-Betadev10.05… > > > > Cheers > > > > Mariano > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 24, 2010

Re: [Pharo-project] About the Pharo Issue tracker

by Mariano Martinez Peck

On Mon, May 24, 2010 at 10:37 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Hi Guille and Carla, > > Yes for certain actions you need to be a committer. I added you both. > Please feel free to help maintaining the issue tracker :) > > I don't like this setting. I rather pharo users (not necessary committers) be able to directly tag. Google code doesn't allow us that or it is just our configuration ? Cheers Mariano > If an issue is not clear and lacking information, please add a note and/or > ask in the mailing list. If an issue cannot be reproduced and the creator > does not provide details, we just switch to "won't fix". > > Another area that needs work is to identify which issues should still be > tackled for 1.1. In the tracker we currently have over 200 issues for > milestone 1.1. Many are of the form "we should do X" and are not critical > for the 1.1 release. Others may be show stopper bugs that need to be fixed. > Identifying the latter is important. > > Cheers, > Adrian > > On May 24, 2010, at 07:10 , Carla F. Griggio wrote: > > > Hmm... if I wanted to change the status of an issue to Fixed (for > example), > > I think I'm not able to do that either. Are you? > > > > Should we be commiters to be able to do these things? > > > > On Mon, May 24, 2010 at 2:04 AM, Carla F. Griggio > > <carla.griggio(a)gmail.com>wrote: > > > >> Welcome, Guille :) It was very cool to have you in the Sprint :) > >> > >> I notice that if I try to post a new issue, I can't categorize it. Who > is > >> able to categorize issues? > >> > >> Carla. > >> > >> 2010/5/23 Guillermo Polito <guillermopolito(a)gmail.com> > >> > >>> Hi! > >>> > >>> First I may introduce myself. My name is Guillermo Polito and I'm from > >>> Argentina. I've been using Pharo for several months with some > colleagues > >>> that are already here to teach OOP in the UTN university, and i've been > >>> suscribed to this mailing list for some time. But it's my first mail > here > >>> :P. > >>> > >>> I participated yesterday in the Pharo Sprint in Argentina and there I > had > >>> my first look at the issue tracker. And well, it seemed to me to be a > >>> little messy. There are lots of issues that aren't properly explained, > some > >>> of them are duplicated, and they are not well organized. > >>> It would be nice to use the labels googlecode provides to give them > some > >>> categorization, so we can browse them in a more intelligent way. Maybe > we > >>> can split the issues in "modules" (like Collection issues, Compiler > Issues, > >>> Closures Issues, Networking Issues...) or something like that. That > will > >>> help in avoiding duplications and looking for issues to solve (because > I can > >>> look for issues in the modules I know the most). > >>> > >>> At the moment I will stay looking for issues i can fix or commenting > the > >>> ones that lacks information :). > >>> > >>> Regards, > >>> Guille > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 24, 2010

Re: [Pharo-project] [BUG] VM crash during debbuging some code by Through button with Transcript>>show: in deepest inner methods

by StÃ©phane Ducasse

http://code.google.com/p/pharo/issues/detail?id=2469 Stef On May 23, 2010, at 4:18 PM, Denis Kudriashov wrote: > I found more bad cases with code simulation. And I think any manipulations with context (errors signals, simaphore, ...) not work in simulation mode. Transcript printing failed because of simaphore accessing (for thread safety) > > I create CodeSimulationTests (see attachement) with some tests which not work and which crash VM. > > Maybe this tests not correct. But I hope it helps to indicate and solve issues > > 2010/5/23 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Thanks! > > Stef > > On May 23, 2010, at 11:13 AM, Denis Kudriashov wrote: > > > And If you replace Transcript code with > > > > self halt. > > > > You will see that debugging with through button does not work. Code simulation failure raised (but without VM crash) > > > > 2010/5/23 Denis Kudriashov <dionisiydk(a)gmail.com> > > I has Pharo1.0 one click, Windows 7. > > I attach class ClassWithTranscriptPrinting. > > see class side method #debug > > > > > > > > > > > > 2010/5/23 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > > > Hi denis > > > > can you report clearly your bug > > - image > > - vm > > - os > > - scenario > > > > I could not compile > > Transcript>>show:'something' > > > > so I do not know how you did it. > > > > > > > > On May 23, 2010, at 10:11 AM, Denis Kudriashov wrote: > > > > > Hello > > > > > > Just insert > > > Transcript>>show:'something' > > > at any method begin. > > > > > > Now debug sender of your method by debugger Through button. > > > > > > If no Transcript opened VM will crash! > > > _______________________________________________ > > > 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 > > <CodeSimulationTests.st>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 24, 2010

Re: [Pharo-project] Rome Canvas to replace an ordinary canvas [Was: Re: Rendering fonts on OpenGL ]

by Igor Stasenko

On 24 May 2010 17:22, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >> Yes, i actually want to do that. > > I'm trying to understand the reason of such a plan? > Is it because like that the clients of existing rendering do not have to be touched? > To make things minimally dependent on implementation. >> >> I plan to inject the new methods into a Morph >> >> Morph>>fullDrawOnRomeCanvas: aCanvas >> Morph>>drawOnRomeCanvas: aCanvas >> >> which should tell the morph to use a different instructions/commands >> to perform drawing, >> to conform with RomeReferenceCanvas protocol. >> >> I don't want to repeat a balloon canvas protocol. > > what was wrong with it? > I did this once for GLCanvas, and don't want to repeat that again :) The Balloon canvas and its uses is too damn focused on blitting, which makes it too hard to provide a backend which doing most things on GPU. If you want to go into vector world, you should keep a distance from any blitting operations. Simply because they are ineffective, CPU hungry and don't scale well. >> >> Then, eventually, when we will have everything ready, >> we will be free to use different rendering backend than Balloon canvas. >> >> And its important to make it a non-intrusive. >> So, the plan is: >> >> - create a separate package, which will contain extension methods >> to Morph and its various subclasses. And maybe some little classes. >> >> - this package !!_should not_!! have any dependencies on Rome , and >> should be loaded cleanly, >> even if you don't have Rome installed. >> It only should conform with Rome canvas protocol for implementing rendering. >> >> This will ensure a backend agnostic nature of new morphic rendering code. >> >> If you think this plan is cool, then lets pick a package name and >> repository, and i will start happy coding :) >> >>>> >>>>> Regards, >>>>> Â Â Â Â Â Â Javier. >>>>> >>>>> 2010/5/23 Igor Stasenko <siguctua(a)gmail.com> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

May 24, 2010

Re: [Pharo-project] Rome Canvas to replace an ordinary canvas [Was: Re: Rendering fonts on OpenGL ]

by StÃ©phane Ducasse

> > Yes, i actually want to do that. I'm trying to understand the reason of such a plan? Is it because like that the clients of existing rendering do not have to be touched? > > I plan to inject the new methods into a Morph > > Morph>>fullDrawOnRomeCanvas: aCanvas > Morph>>drawOnRomeCanvas: aCanvas > > which should tell the morph to use a different instructions/commands > to perform drawing, > to conform with RomeReferenceCanvas protocol. > > I don't want to repeat a balloon canvas protocol. what was wrong with it? > > Then, eventually, when we will have everything ready, > we will be free to use different rendering backend than Balloon canvas. > > And its important to make it a non-intrusive. > So, the plan is: > > - create a separate package, which will contain extension methods > to Morph and its various subclasses. And maybe some little classes. > > - this package !!_should not_!! have any dependencies on Rome , and > should be loaded cleanly, > even if you don't have Rome installed. > It only should conform with Rome canvas protocol for implementing rendering. > > This will ensure a backend agnostic nature of new morphic rendering code. > > If you think this plan is cool, then lets pick a package name and > repository, and i will start happy coding :) > >>> >>>> Regards, >>>> Javier. >>>> >>>> 2010/5/23 Igor Stasenko <siguctua(a)gmail.com> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> 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 >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 24, 2010

[Pharo-project] Need someone to test if NBOpenGL works for you on win32

by Igor Stasenko

Hi, i just snapshotted my stuff with various fixes, to make it load cleanly on pharo and squeak images. I'd like you to ask to test and load it and tell me if it works for you. Currently it works only on win32 platform. It could work on Linux, but i didn't had time to port it yet. There is no automatic installation procedure right now, so here what you should try: - first, you need to have VM with NativeBoost plugin + NativeBoost loaded into an image (see http://code.google.com/p/nativeboost/wiki/Installation for instructions) - then load the OpenGL stuff from http://www.squeaksource.com/NBOpenGL in following order: - NBOpenGL-Core - NBOpenGL-Win - NBOpenGL-TrueType - NBOpenGL-Display - NBOpenGL-Morphic i tried the above on Pharo-1.1-11367-Betadev10.05.1.image , which were released recently, and it seems works ok. on squeak/trunk it should also work without problems. Now, if everything went right, then we're ready to run a demo: GLViewportMorph new "useOwnForm: true;" openInWorld This thing should render a TrueType glyphs and animating a smooth zoom of it. Nothing fancy, i just wanna know, if it works for you (and how well). :) As you may know, GPU/OpenGL implementations vary depending on vendor and how old your hardware is, and i don't have all of it at my disposal. Ok.. if you got it running, and it renders the glyphs.. there's one thing left: - save your image and quit (without closing this morph) - start image it should continue working as if nothing happens. -- Best regards, Igor Stasenko AKA sig.

May 24, 2010

Re: [Pharo-project] Rome Canvas to replace an ordinary canvas [Was: Re: Rendering fonts on OpenGL ]

by Igor Stasenko

Just an idea how to call the package: Romph-Rendering if you swizzle first 3 letters, you'll get Morph-Rendering :) On 24 May 2010 14:36, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 24 May 2010 13:36, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >> On May 23, 2010, at 11:04 PM, Igor Stasenko wrote: >> >>> 2010/5/23 Javier PimÃ¡s <elpochodelagente(a)gmail.com>: >>>> Hi, may I ask how you are rendering these fonts? You parse the glyphs and >>>> then render lines with opengl or use freetype to render to a texture without >>>> antialiasing or both? >>> >>> Squeak has already a TT font reader, so i just taking the data from there >>> and piping to GPU. >>> What you see here is freely scalable vector/curve rendering done >>> completely on GPU. >>> >>>> If you asked me, I'd say I like the method but for >>>> fonts they look a bit blury, I'd say too much for the smaller ones. >>> >>> I think this is best what you can achieve without hinting / subpixel AA. >>> >>>> Also, what are you working on? >>>> >>> I once did a GLCanvas, >>> and now i want to reiterate and improve it using new callout mechanism >>> (NativeBoost), >>> and full coverage of OpenGL API, with all extensions available at your disposal. >> >> Igor it would be good it we could have >> >> NativeBoostRomeCanvas >> >> if you see what I mean :) >> > > Yes, i actually want to do that. > > I plan to inject the new methods into a Morph > > Morph>>fullDrawOnRomeCanvas: aCanvas > Morph>>drawOnRomeCanvas: aCanvas > > which should tell the morph to use a different instructions/commands > to perform drawing, > to conform with RomeReferenceCanvas protocol. > > I don't want to repeat a balloon canvas protocol. > > Then, eventually, when we will have everything ready, > we will be free to use different rendering backend than Balloon canvas. > > And its important to make it a non-intrusive. > So, the plan is: > > - create a separate package, which will contain extension methods > to Morph and its various subclasses. And maybe some little classes. > > - this package !!_should not_!! have any dependencies on Rome , and > should be loaded cleanly, > even if you don't have Rome installed. > It only should conform with Rome canvas protocol for implementing rendering. > > This will ensure a backend agnostic nature of new morphic rendering code. > > If you think this plan is cool, then lets pick a package name and > repository, and i will start happy coding :) > >>> >>>> Regards, >>>> Â Â Â Â Â Â Javier. >>>> >>>> 2010/5/23 Igor Stasenko <siguctua(a)gmail.com> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> 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 >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

May 24, 2010

[Pharo-project] Rome Canvas to replace an ordinary canvas [Was: Re: Rendering fonts on OpenGL ]

by Igor Stasenko

On 24 May 2010 13:36, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On May 23, 2010, at 11:04 PM, Igor Stasenko wrote: > >> 2010/5/23 Javier PimÃ¡s <elpochodelagente(a)gmail.com>: >>> Hi, may I ask how you are rendering these fonts? You parse the glyphs and >>> then render lines with opengl or use freetype to render to a texture without >>> antialiasing or both? >> >> Squeak has already a TT font reader, so i just taking the data from there >> and piping to GPU. >> What you see here is freely scalable vector/curve rendering done >> completely on GPU. >> >>> If you asked me, I'd say I like the method but for >>> fonts they look a bit blury, I'd say too much for the smaller ones. >> >> I think this is best what you can achieve without hinting / subpixel AA. >> >>> Also, what are you working on? >>> >> I once did a GLCanvas, >> and now i want to reiterate and improve it using new callout mechanism >> (NativeBoost), >> and full coverage of OpenGL API, with all extensions available at your disposal. > > Igor it would be good it we could have > > NativeBoostRomeCanvas > > if you see what I mean :) > Yes, i actually want to do that. I plan to inject the new methods into a Morph Morph>>fullDrawOnRomeCanvas: aCanvas Morph>>drawOnRomeCanvas: aCanvas which should tell the morph to use a different instructions/commands to perform drawing, to conform with RomeReferenceCanvas protocol. I don't want to repeat a balloon canvas protocol. Then, eventually, when we will have everything ready, we will be free to use different rendering backend than Balloon canvas. And its important to make it a non-intrusive. So, the plan is: - create a separate package, which will contain extension methods to Morph and its various subclasses. And maybe some little classes. - this package !!_should not_!! have any dependencies on Rome , and should be loaded cleanly, even if you don't have Rome installed. It only should conform with Rome canvas protocol for implementing rendering. This will ensure a backend agnostic nature of new morphic rendering code. If you think this plan is cool, then lets pick a package name and repository, and i will start happy coding :) >> >>> Regards, >>> Â Â Â Â Â Â Javier. >>> >>> 2010/5/23 Igor Stasenko <siguctua(a)gmail.com> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

May 24, 2010

[Pharo-project] [ENH] CompiledMethodTrailer with a different CompiledMethod class

by Igor Stasenko

Hello, i added a simple enhancement to make CompilerMethodTrailer to be more friendly with CompiledMethod subclasses. It provides an additional method #createMethod:header:methodClass: which allows to create a compiled method with other class, than a CompiledMethod. Installing it requires 2 separate phases: phase1 - adds #createMethod:header:methodClass: method phase2 - puts this method in use. if you merge these changesets, you'd will run into a problem, because filein/fileout utility does not honors the order of changes, how they should be applied. On 24 May 2010 13:27, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > and send us the fix for inclusion :) > > On May 24, 2010, at 10:54 AM, Igor Stasenko wrote: > >> On 24 May 2010 10:31, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: >>> Hello >>> >>> Just to make a little note. I'm adapting the lightweight classes >>> package to work with CompilerMethodTrailer. In this method >>> >>> CompiledMethodTrailer>>createMethod: numberOfBytesForAllButTrailer >>> header: headerWord >>> Â Â Â Â | meth | >>> Â Â Â Â encodedData ifNil: [ self encode ]. >>> Â Â Â Â meth := CompiledMethod newMethod: numberOfBytesForAllButTrailer + >>> size header: headerWord. >>> Â Â Â Â ... >>> >>> I need to answer a different kind of CompiledMethod, it would be nice >>> if my own CompiledMethod class could be specified in some way to make >>> the CompiledMethodTrailer more flexible. >> >> Yes, you could add a class parameter, so method will take 3 >> >> createMethod: numberOfBytesForAllButTrailer header: headerWord class: >> aMethodClass >> >>> Cheers, >>> >>> HernÃ¡n >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

May 24, 2010

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

by StÃ©phane Ducasse

Hi veronica I wanted to use Torch to check inbox published change and I get TCTrait>>parAuthorAlia.... When I tried to look at Slice-hasEqualElement (using Torch build on 11370) Stef 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

May 24, 2010