[Pharo-project] Smalltalks 2012 - 6th International Conference on Smalltalk Technologies - Call for papers
[Apologies if you receive multiple copies of this Call for Papers] CALL FOR PAPERS SMALLTALKS 2012 6th International Conference on Smalltalk Technologies http://www.fast.org.ar/smalltalks2012 Research Track: Call for Papers - http://scg.unibe.ch/wiki/events/smalltalks12 November 3th - 5th, 2012 Important dates: Submission (Hard Deadline): September 17th, 2012 (Argentinian time: UTC/GMT -3 hours). Notification of acceptance: October 8th, 2012. Camera Ready Submission: November 2nd, 2012. - Conference Location: Universidad Nacional de Quilmes (Argentina) The Smalltalks series of conferences (www.fast.org.ar) is a lively forum on Smalltalk-based software technologies that brings together more than 200 people from both academia and industry for a period of three days. Past editions of Smalltalks have included many high-quality presentations from industry and research. These contributions have shown interesting applications of Smalltalk, advances in the Smalltalk language, didactic uses of Smalltalk and so on. Similar to last year, Smalltalks 2012 will include a dedicated research track. We welcome submissions to this research track presenting original scientific contributions to, or using, Smalltalk in general. Topics of interest include, but are not restricted to: -Aspects, Aspect Languages and Applications. -Ambient Intelligence, Ubiquitous / Pervasive Computing and Embedded Systems. -Compilation Technology, Optimization, Virtual Machines. -Educational Material. -Language Engineering, Extensions. -Model Driven Engineering / Development. -Meta-Modeling, Reflection and Meta-programming. -Programming in the Large, Design, Architectures and Components. -Programming Environments, Browsers, User Interfaces, UI Frameworks. -Source-code analysis and manipulation (Static analysis, refactoring, type inference, metrics). -Team Management. -Testing, Extreme Programming / Practices. -Web Services, Internet Applications, Event-driven Programming. -Experience Reports. Important dates: Submission (Hard Deadline): September 17th, 2012 (Argentinian time: UTC/GMT -3 hours). Notification of acceptance: October 8th, 2012. Camera Ready Submission: November 2nd, 2012. Papers: Papers should be written in English, in PDF-format and should not exceed 15 pages (including references and figures), using the JOT journal format. Templates for LaTeX formats can be found at http://www.jot.fm/authors.html Papers must be submitted through the EasyChair submission web site at http://www.easychair.org/conferences/?conf=smalltalks12 The accepted papers will be digitally available on the conference website. We are currently negotiating a special edition of a journal for which the best papers will get invited. Papers submitted must not have been previously published and must not be under review for publication elsewhere. Papers must strictly adhere to submission guidelines. If you have questions, please send an e-mail to Jorge Ressia (res...@iam.unibe.ch) Special Issue Publication -- The best papers will be invited to submit an extended version of their work in a special issue of the International Journal JOT (The Journal of Object Technology), http://www.jot.fm/ Program Committee -- - Alexandre Bergel (DCC, Universidad de Chile, Chile) - Andy Kellens (Vrije Universiteit Brussel, Belgium) - Coen De Roover (Vrije Universiteit Brussel, Belgium) - Damien Cassou (Hasso-Plattner-Institut, Potsdam, Germany) - Gabriela Arevalo (Universidad Nacional de Quilmes, Argentina) - Gonzalo Zabala (Universidad Abierta Interamericana, Argentina) - Hernan Wilkinson (Universidad de Buenos Aires, Argentina) - Jannik Laval (INRIA Lille/LABRI Bordeaux, France) - Johan Fabry (DCC, Universidad de Chile, Chile) - Luc Fabresse (Ecole des Mines Douai, France) - Lukas Renggli (Google, Switzerland) - Marcus Denker (INRIA Lille, France) - Mircea Lungu (University of Bern, Switzerland) - Noury Bouraqadi (Ecole des Mines Douai, France) - Serge Stinckwich (Institut de recherche pour le developppement, France) - Tudor Girba (Sw-eng. Software Engineering GmbH, Switzerland) Program Chair Jorge Ressia (Univeristy of Bern, Switzerland) -- Jorge Ressia www.jorgeressia.com
Re: [Pharo-project] Package TextLint for Debian?
Hi Thomas, I agree with Damien. If you need a hand I am willing to help. Cheers, On Tue, Feb 21, 2012 at 9:47 AM, Damien Cassou wrote: > Dear Thomas, > > On Tue, Feb 21, 2012 at 9:40 AM, Thomas Koch wrote: > > I've just found textlint for Emacs[1] and wondered, whether it could be > > packaged for Debian (or any other Distro). Unfortunately the Git repo > does not > > contain the source code of textlint but only several binaries. So I > wondered > > whether all the textlint logic happens locally or whether the plugin > contacts > > a textlint server? > > > > [1] https://github.com/DamienCassou/textlint > > > > Even if the textlint source code would be available, it seems that > textlint > > depends on Pharo, which also isn't packaged for Debian. Is that right? I > don't > > know anything about Smalltalk, so I can't package Pharo myself, but I'd > be > > happy to help if somebody of you would be interested to package it. > > I'm really interested in getting TextLint distributed as a debian and > ubuntu packages. If you can lead this, I will help you as much as I > can. I don't think you need a package for Pharo itself. Just try to > create a package from what is on github: the pharo image + VM + bash > and emacs scripts. You can send me private emails. > > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > -- Jorge Ressia www.jorgeressia.com
Re: [Pharo-project] SqueakSource
It is working Cheers, On Thu, Dec 1, 2011 at 8:14 AM, Sven Van Caekenberghe wrote: > Can someone please have another look at SqueakSource, it is down ? > > Thx, > > Sven > > -- Jorge Ressia www.jorgeressia.com
Re: [Pharo-project] crash of the vm on ubuntu
Hi guys, Flushing the selector is enough. Eliot fixed this problem some time ago. Look at the discussion http://forum.world.st/Re-Pharo-project-Troubles-with-flushCache-and-run-with-in-td3659114.html @Alex I have a test case that I built for Eliot. If you send me your image and VM I can try out to see if there is a similar problem. Cheers, On Fri, Nov 4, 2011 at 3:31 PM, Mariano Martinez Peck wrote: > Flushing the behavior is way too much, since if I understand correctly, it > will flush the whole method cache (including PICs etc ). > In my experience, with the latest version, just flushing the selector is > enough. It is not in your case? > > Cheers > > > On Fri, Nov 4, 2011 at 3:18 PM, Alexandre Bergel > wrote: > >> > What is still not clear to me is what you need to flush when replacing >> a method with an object. The selector, the old method, the new method, or >> the behavior? Last time I tried I got the best results flushing the >> behavior, but I would like to know what should be used for real. >> >> +1 >> I also flush the behavior. >> >> Alexandre >> >> > >> > On Friday, 4 November 2011, Alexandre Bergel >> wrote: >> > > Ok >> > > Thanks, we will try >> > > >> > > Alexandre >> > > >> > > >> > > On 4 Nov 2011, at 11:01, Mariano Martinez Peck wrote: >> > > >> > >> >> > >> >> > >> On Fri, Nov 4, 2011 at 2:14 PM, Alexandre Bergel < >> alexandre.ber...@me.com> wrote: >> > >> Hi! >> > >> >> > >> My students are experiencing frequent crashes of the CogVM when >> playing with Spy (a profiling framework that instrument compile methods and >> replace them during the execution). My students use a MooseOneClick bundle. >> I am not sure which version of the CogVM they use actually. Is there a way >> to check this? >> > >> >> > >> Anyone has experienced frequent crashes with Ubuntu? >> > >> >> > >> There were some issues with #cannotInterpret: and #run:with:in with >> previous versions of Cog. However, with the last version Eliot' Cog all of >> them are fixed >> > >> >> > >> >> > >> Cheers, >> > >> Alexandre >> > >> -- >> > >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> > >> Alexandre Bergel http://www.bergel.eu >> > >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> -- >> > >> Mariano >> > >> http://marianopeck.wordpress.com >> > >> >> > > >> > > -- >> > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> > > Alexandre Bergel http://www.bergel.eu >> > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > >> > -- >> > Lukas Renggli >> > www.lukas-renggli.ch >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Jorge Ressia www.jorgeressia.com
Re: [Pharo-project] Omnibrowser in 1.4
Hi guys, I am completely for inventing something new. However, I do not think this is the right model for doing so. In a sense we are getting static, we put some tools in the image and expect people to use them. I think that this is going to be contra productive. I believe that a much better model would be a dynamic one in which people can load the tools that make them more productive. Moreover, this model will force us, developers, to better target our tools. Make clear which are their objectives, showing their benefits, improve their design for understandability and extension and thus getting feedback and interested people. At the end better tools will emerge. In a word, better products, with a "natural selection" process. HTH, Jorge On Mon, Aug 29, 2011 at 10:37 PM, Lukas Renggli wrote: >>>> Is the current system simple and minimal? >>> >>> No, it is complex and it is getting bigger with every release. >> >> No, i wouldn't say so. >> >> Most fixes and improvements are still about cleaning things out and fixing >> bugs. >> But not about new features. > > Yes, you are right. In fact Pharo 1.4 is roughly 1 MB smaller than Pharo 1.3. > >> Even if you consider Zinc as a movement towards "getting bigger", >> consider an alternative: >> having library which follows standards, or keep using hacks which were >> not complete and useful only >> for most simple cases. > > Zinc is an excellent example, because it is fully backward compatible. > I don't see that with RPackage, SystemAnnouncements, Ring, Shout > (before Alan fixed it), with the proposed RB changes, ... > >> I am also against growing system unless it is necessarily. >> In 1.3. i added a new 'non-interactive' mode and non-interactive ui >> manager. And this was necessarily, because we need a way >> to deal with "hanging images" in headless mode. >> Now we can run images on jenkins, knowing that it will never enter >> 'click ok to proceed' state. > > Yes, this is cool. > >>>> Do you think the Pharo we have is good enough to have a future? >>> >>> No, there is a lot to be improved. I think the future of Pharo is what >>> can be built on top, not what can be integrated and forced upon >>> everybody. >> >> Lukas, there is nobody forcing anyone. >> How we (or anyone else) can force people to use Pharo? > > Right, but you can easily force people not to follow. I don't > understand why all the people that still use Pharo 1.0 or 1.1 don't > speak up? > >> A new and 'unproven' tools are 'forced' into images mainly to collect >> feedback. >> And i think it is good strategy, because most people *including me* >> are too busy/lazy to go & download and install new stuff and try it >> out. > > Don't we have all these automatic builds with all these tools > pre-loaded? There could be a list of links to these builds on the > website and like/+1/report buttons. That would likely yield some > discussions and give some time to investigate ... > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > -- Jorge Ressia www.jorgeressia.com
Re: [Pharo-project] Omnibrowser in 1.4
+1 On Mon, Aug 29, 2011 at 3:26 PM, Max Leske wrote: > +1 > > On 29.08.2011, at 14:51, Torsten Bergmann wrote: > > Yes, there were times when other IDE's got their ideas from > Smalltalk and I think now we should look at some ideas from > mainstream IDE's. > -- Jorge Ressia www.jorgeressia.com
Re: [Pharo-project] squeaksource down
Doru, We are fixing the problem. On Sun, Aug 21, 2011 at 10:28 AM, Tudor Girba wrote: > Bifrost-JorgeRessia.166 is also missing. > > Doru > > > On 21 Aug 2011, at 10:16, Tudor Girba wrote: > >> It looks like some code is missing. For example: >> GT-Tools-TudorGirba.96 >> GT-Tools-TudorGirba.97 >> >> I am raising the issue because maybe others lost code, too. >> >> Doru >> >> >> On 21 Aug 2011, at 10:00, Jorge Ressia wrote: >> >>> It is working >>> >>> On Sun, Aug 21, 2011 at 12:27 AM, Mariano Martinez Peck >>> wrote: >>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>>> >>>> >>> >>> >>> >>> -- >>> Jorge Ressia >>> www.jorgeressia.com >>> >> >> -- >> www.tudorgirba.com >> >> "Reasonable is what we are accustomed with." >> > > -- > www.tudorgirba.com > > "Yesterday is a fact. > Tomorrow is a possibility. > Today is a challenge." > > > > > -- Jorge Ressia www.jorgeressia.com
Re: [Pharo-project] squeaksource down
It is working On Sun, Aug 21, 2011 at 12:27 AM, Mariano Martinez Peck wrote: > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Jorge Ressia www.jorgeressia.com
Re: [Pharo-project] [Vm-dev] Re: Troubles with #flushCache and #run:with:in:
Hi Eliot, I am experiencing the same problem as Lukas. I was having random DNU on replaced methods. I fixed the problem by flushing the cache on the compiled methods only, before I was flushing on the selector and on the class. It is not yet clear to me what is the right way of flushing the cache. Any explanation on that? I think that this goes along with http://code.google.com/p/pharo/issues/detail?id=2255 http://forum.world.st/flushCache-with-MethoWrappers-in-CogVM-td3381310.html Eliot, if you need help debugging or testing a potential solution let me know, I have a bunch of test working on top of this. Cheers, On Mon, Jul 11, 2011 at 6:31 PM, Eliot Miranda wrote: > > Hi All, > I'm in touch with Lukas on this but have no time to address it right now. > worry not :) > > On Mon, Jul 11, 2011 at 3:05 AM, Mariano Martinez Peck > wrote: >> >> >> Maybe cc'ing VM mailing list can help. >> >> On Fri, Jul 1, 2011 at 9:32 AM, Lukas Renggli wrote: >>> >>> Hi Eliot, >>> >>> I am using one of the latest VMs from your site (VM.r2434) and I >>> continue to have subtle problems with objects as methods (#flushCache, >>> #run:with:in:). >>> >>> The issue is that the test coverage in Pharo is kind of broken on Cog >>> for a long time already. It reports methods as not covered that are >>> clearly covered, and tests seem to randomly fail. >>> >>> I suspected that there is something wrong with the coverage code >>> itself. So I started to experiment with TestCoverage>>flushCache and >>> noticed that the current implementation >>> >>> TestCoverage>>flushCache >>> self reference methodSymbol flushCache >>> >>> performs not that well: The set of not covered methods is wrong and >>> many tests suddenly fail. If I replace it with >>> >>> TestCoverage>>flushCache >>> self reference actualClass flushCache >>> >>> I actually get accurate coverage information, but there are still a >>> few tests constantly failing. I tried to use all possible combinations >>> of #flushCache (also calling it on the compiled method), but only >>> flushing the cache on the class seems to work properly. So far so >>> good, but I really wonder what the correct way is to flush the cache? >>> :-) >>> >>> For my experiments I was using the package 'AST-Tests-Semantics'. This >>> is a small package with lots of test methods that cover each method >>> but one (RBSemanticAnnotationMisssing>>#isResumable). Now the "real" >>> problem is that when running these tests in coverage mode, the same 4 >>> tests always fail: >>> >>> RBSemanticTest>>testBlockScope >>> RBSemanticTest>>testCascadeReceiver >>> RBSemanticTest>>testClassVariableBinding >>> RBSemanticTest>>testGlobalVariableBinding >>> >>> Not sure of how to debug that? Do you have an idea why these otherwise >>> passing tests suddenly fail? If you want to try to reproduce you can >>> use any Pharo image with the tests loaded, or use those that I used: >>> >>> >>> http://jenkins.lukas-renggli.ch/job/Development/lastSuccessfulBuild/artifact/omnibrowser-tests/omnibrowser-tests.changes >>> >>> http://jenkins.lukas-renggli.ch/job/Development/lastSuccessfulBuild/artifact/omnibrowser-tests/omnibrowser-tests.image >>> >>> Open the Test Runner, select 'AST-Tests-Semantics' and 'Run Coverage'. >>> >>> Any help or clarification would be appreciated :-) >>> >>> Lukas >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > > > > -- > best, > Eliot > > -- Jorge Ressia www.jorgeressia.com
Re: [Pharo-project] Squeaksource is down :(
It is working Cheers, On Sun, Aug 7, 2011 at 4:45 PM, Stéphane Ducasse wrote: > > > -- Jorge Ressia www.jorgeressia.com
Re: [Pharo-project] Squeaksource down?
It is working On Tue, Aug 2, 2011 at 9:27 AM, Cyrille Delaunay wrote: > Hello, > I am not able to connect to squeaksource -- Jorge Ressia www.jorgeressia.com
Re: [Pharo-project] squeaksource down?
It is working On Mon, Aug 1, 2011 at 4:00 PM, Camillo Bruni wrote: > http://www.downforeveryoneorjustme.com/squeaksource.com -- Jorge Ressia www.jorgeressia.com
Re: [Pharo-project] SqueakSource down
Hi, it is working. On Thu, Jul 14, 2011 at 8:38 AM, Pavel Krivanek wrote: > SqueakSource is currently down. > > -- Pavel > > -- Jorge Ressia www.jorgeressia.com
Re: [Pharo-project] something never happened before
Hi guys, It is working On Sat, Jun 18, 2011 at 9:21 AM, Norbert Hartl wrote: > > > Am 17.06.2011 um 22:45 schrieb Esteban Lorenzano : > >> hey, guess what! >> >> squeaksource is down! >> > What a shitty indicator of success, right? :) > > Norbert > > -- Jorge Ressia www.jorgeressia.com
Re: [Pharo-project] squeaksource is dying
Hi guys, It is working. Cheers, On Thu, Jun 16, 2011 at 11:18 PM, Eliot Miranda wrote: > > > On Thu, Jun 16, 2011 at 2:15 PM, laurent laffont > wrote: >> >> . or maybe just down > > according to the site it's down. >> >> >> Laurent > -- Jorge Ressia www.jorgeressia.com
Re: [Pharo-project] squeaksource is down :(
fixed On Mon, May 16, 2011 at 10:52 AM, Mariano Martinez Peck wrote: > Thanks > > -- > Mariano > http://marianopeck.wordpress.com > > -- Jorge Ressia www.jorgeressia.com
Re: [Pharo-project] Better debugging...
Hi guys, Stef, Bifröst was invented for this particular purpose. http://scg.unibe.ch/research/bifrost Bifröst is a unified approach to reflection. Stef, if you explain a little bit the use case I can quickly provide an adaptation solution. HTH, Jorge On Mon, Apr 25, 2011 at 11:29 PM, Camillo Bruni wrote: > I think a nice way to have a decent debugger is to run the program on top of > a changeable interpreter. Since a classical debugger is nothing else but an > interpreter with slightly changed semantics. > > The object flow VM does a great job at tracing back stuff.. however it might > pose a massive overhead since it collects tons and tons of data. > > In Pinocchio[1] we implemented very nice and simple debuggers by "just" > changing the current interpreter to take a user-action into account on each > message send. Since this is implemented on top of a metacircular interpreter > this was quite simple to achieve. So the whole implementation of the known > debugger functionality (step, over...) maybe took an afternoon. Since you > have access to the full interpreter protocol it is very easy to intercept > different sorts of actions. As described in the linked paper, it was very > easy to implement the object-flow behavior in Pinocchio. > > So for me there is only one real way to have a decent debugger. And that > means that it is a first-class interpreter whose semantics I can change at > will. Thus I can create a specific debugger for my applications. > > But I guess that making the first-class interpreters work right away in Pharo > will take a while to do, hence I propose the following additions to the > current interpreter to make it partly useable: > > - interception of message sends > - per thread [ok] > - of specific classes [missing] > - of specific instances [missing] > > - interception of instance variable access, read/write > - per thread [missing] > - of specific classes [missing] > - of specific instances [missing] > - of specific instance variables [missing] > > Furthermore I really want to be able to script all of that stuff, eg. provide > a simple test block that gets invoked on each message send. Returning true => > halt, Returning false => continue execution. > > > [1] http://scg.unibe.ch/archive/papers/Verw10aPinocchio.pdf > -- Jorge Ressia www.jorgeressia.com
Re: [Pharo-project] [participants-ecole-mars2011] About the sprint saturday 12
I will be there until 15 hs Cheers, On Thu, Mar 3, 2011 at 9:14 PM, Henrik Johansen wrote: > Not leaving untill Sunday, I'll be there! > > Cheers, > Henry > > Den 3. mars 2011 kl. 17:30 skrev Stéphane Ducasse : > >> Hi guys and participants of the school, >> >> we proposed to organize a spring saturday 12 so that you can get involved >> and get the feel >> of a fun coding party. Now we need to know if you plan to participate so >> that we >> can reserve a room and prepare something for lunch. >> >> So could you reply to this email so that we know what we should prepare. >> >> Stef > > -- Jorge Ressia www.jorgeressia.com
Re: [Pharo-project] Fwd: [ANN] pharo focused sprint - bern, feb 26
I will be there too. Cheers, On Wed, Feb 23, 2011 at 10:44 PM, Tudor Girba wrote: > Excellent. > > Doru > > > On 23 Feb 2011, at 22:29, Lukas Renggli wrote: > >> I am coming too. >> >> Lukas >> >> On 23 February 2011 05:27, Tudor Girba wrote: >>> Great. >>> >>> Doru >>> >>> >>> On 22 Feb 2011, at 19:47, Camillo Bruni wrote: >>> >>>> I'll be there. >>>> >>>> From what I have done this week so far, I would like to work on extending >>>> the IDE and reduce the amount of clicks / keystrokes to browse things... >>>> >>>> m(o_o)m >>>> camillo >>>> >>>> On 2011-02-21, at 19:42, Tudor Girba wrote: >>>> >>>>> Hi, >>>>> >>>>> I would like to remind you that this Saturday, February 26, we organize a >>>>> Sprint at SCG, University of Berne, Switzerland (room 107): >>>>> http://scg.unibe.ch/contact/maps >>>>> >>>>> Further details can be found below. Please let us know by mail if you >>>>> plan to attend and what you would wish to work on (see below). >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>> >>>>> Begin forwarded message: >>>>> >>>>>> From: Tudor Girba >>>>>> Date: 1 February 2011 16:38:30 CET >>>>>> To: "Pharo-project@lists.gforge.inria.fr Development" >>>>>> >>>>>> Cc: Adrian Lienhard >>>>>> Subject: [ANN] pharo focused sprint - bern, feb 26 >>>>>> >>>>>> Hi, >>>>>> >>>>>> We would like to organize a Pharo Sprint on Saturday, February 26 at >>>>>> SCG, University of Berne, Switzerland (room 107): >>>>>> http://scg.unibe.ch/contact/maps >>>>>> >>>>>> Unlike other sprints, this would not be about fixing things from the >>>>>> tracker, but about building something new and reviewing the situation >>>>>> around one central topic. For this one, the main topic will be Morphic >>>>>> and the IDE. Why? Because it is time to rethink our day-to-day tools and >>>>>> bring them closer to this century (ok, maybe decade :)). It is Ok if you >>>>>> are not a specialist. It is more important to want to participate and >>>>>> learn. The rest will come in time. >>>>>> >>>>>> * Please let us know by mail if you plan to attend and what you >>>>>> would wish to work on (see below). >>>>>> >>>>>> Proposed tasks (other tasks are possible in the same area): >>>>>> - Enhancements of Morphic widgets: >>>>>> --- TabGroupMorph with lazy pages, closable tabs, overflow handling and >>>>>> toolbars (a start exists in Glamour) >>>>>> --- High level support for collapsable panes (based on the input of Gary) >>>>>> --- SearchMorph with multiple groups of items (like in Spotlight) >>>>>> --- MorphTreeMorph integrated with GeneralScrollPane to allow for space >>>>>> filling >>>>>> --- BreadcrumbMorph >>>>>> --- Hyperlinks in TextMorphs >>>>>> - Test and enhance the current IDE >>>>>> - Evaluate TextMorphs: NewTextMorph, PluggableTextMorph, >>>>>> SMxPluggableTextMorph etc >>>>>> - Prototype a new ToolSet solution >>>>>> - Enhancements of Glamour and of the Glamorous Toolkit >>>>>> --- Debugger >>>>>> --- Coder >>>>>> --- Multipage Workspace >>>>>> --- CodeBubbles >>>>>> - Develop WeakAnnouncement (start from the implementation of Lukas) >>>>>> - Evaluate the various keybinding implementations >>>>>> - Evaluate ToolBuilder >>>>>> - Evaluate the path to adopt SimpleMorphic >>>>>> >>>>>> A second working topic is getting Monticello faster, but this will only >>>>>> be tackled if there are enough people for the first one. >>>>>> >>>>>> Cheers, >>>>>> Adrian and Doru >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> www.tudorgirba.com >>>>>> >>>>>> "Be rather willing to give than demanding to get." >>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "It's not how it is, it is how we see it." >>>>> >>>>> >>>> >>>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Value is always contextual." >>> >>> >>> >>> >>> >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > -- > www.tudorgirba.com > > "There are no old things, there are only old ways of looking at them." > > > > > -- Jorge Ressia www.jorgeressia.com
Re: [Pharo-project] What happened to demo mode?
Hi Oscar, I found this explanation from Alain, in Pharo 1.0 Preferences setDemoFonts in Pharo 1.1 from the setting browser, style button (top button bar) then load item then you choose demo mode. or DemoSettingStyle new load The steps for Pharo 1.1 work well for the latest image. Cheers, On Sun, Oct 24, 2010 at 9:51 AM, Oscar Nierstrasz wrote: > > > There used to be a fast way to set LARGE FONTS for showing a demo with Pharo. > Is that hidden away somewhere now? > > I can only find individual settings for the fonts in multiple places. > > Demo mode is really, *really* important! Please put it back if it is > missing, and make it really easy to find! > > - on > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Jorge Ressia www.jorgeressia.com ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] TextLint questions and feedback
g moves nor to loose focus when saving.
>>> 2.b) sometimes (I cannot reproduce) the order of the rules
>>> changes...and this is not good because I was going in order, one by one, and
>>> suddenly they are re-ordered. Maybe you are using a Set for that? using a
>>> simple OrderedCollection could help.
>>>
>>> 3) If you edit the text (and it differs in the amount of characters), and
>>> DO NOT save it, the following color highlighting are moved. It seems you
>>> keep the position in the file, and until it is saved, rules results are
>>> pointing to "unupdated" file. Of course, when I save the file, they are
>>> correct. I guess this is from a performance point of view, but maybe you
>>> have a little hack to do and make it better.
>>>
>>> 4) The rule "no white space before punctuation mark" showed me things I
>>> didn't understand. For example, it says this line there is a "," (comma) :
>>>
>>> \item[ Shared object ] In the case of the \emph{shared objects}, it is
>>> almost the same as in the \emph{inner objects}. An .
>>>
>>> 5) Rules comments clearer. For example, when you say "Avoid using a lot,
>>> it weakens the sentence" It would be better to put "Avoid using "a lot", it
>>> weakens the sentence"
>>> or "Avoid using *a lot*, it weakens the sentence"
>>> or something to clearly mark the words not to use. Because sometimes the
>>> words are confused with the context. Or this one:
>>>
>>> "After an only words beginning with a vowel are allowed. "
>>> should be "After "an" only words beginning with a vowel are allowed."
>>>
>>> 6) For the rules of long sentences/paragraph it would be nice to ignore
>>> \fotenote{}
>>>
>>> 7) Maybe this link is of interest for you:
>>> http://matt.might.net/articles/shell-scripts-for-passive-voice-weasel-words-duplicates/
>>>
>>> Apart from all these things, the tool is very useful and I like it.
>>>
>>> thanks
>>>
>>> Mariano
>>>
>>>
>>
>
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
--
Jorge Ressia
www.jorgeressia.com
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] TextLint questions and feedback
Ok, Done.
There is a new rule called TLConnectorRepetitionInParagraphRule, it is
going to be in the style by default.
It performs the analysis on each paragraph unit.
Cheers,
On Thu, Sep 23, 2010 at 9:00 PM, Mariano Martinez Peck
wrote:
>
>
> On Thu, Sep 23, 2010 at 8:07 PM, Jorge Ressia
> wrote:
>>
>> Hi Mariano,
>>
>> We are very happy that you found TextLint that useful. As you might
>> have noticed we fixed several of your reported issues and we are still
>> working on the remaining ones.
>
> yes, thanks a lot :)
>
>>
>> 1.- Not difficult. Could you specify how this rule would work? how
>> many sentences should we take into account? Perhaps a whole paragraph.
>> You might find the rule TLWordRepetitionInParagraphRule, which is
>> already in TextLint useful, it detects the repetition of words in a
>> paragraphs. If the Word is used more than 3 times then the rule fails.
>> This will include the connectors that you mentioned. If you required a
>> repetition rule a little more strict you can always use this rule as a
>> basis for defining your new rule. We will be more that happy to
>> integrate it :)
>
> Maybe the rule can be very similar to the one you say. My scenario is the
> following: several times I need connectors or things like:
> "However, In contrast to, In adddition, Furthermore, On the other hand,
> Still, Furthermore, Nevertheless, etc".
> And then I need one of them, I usually have to check near that place where I
> need it, if I have already use one of them. I check in the same paragraph or
> just near.
>
> So a rule can be something like TLWordRepetitionInParagraphRule but:
>
> - I wouldn't like to repeated even twice (not 3!!). I just want them only
> once in the near text
>
> - I wouldn't do it for ALL words, only for those kind of words
>
> - I would check in the same paragraph or maybe 10 (15, or 20) lines before
> and after the place.
>
>
>>
>> 2.- The objective behind "Do not join sentences with commas " is
>> simplicity. If you have a sentence with a single comma you might be
>> expressing two different things and divide them in two sentences might
>> be good. On the other hand, if you still want to keep your sentence
>> together this rule might signal that it might be a way of avoiding the
>> use of the coma and using some meaningful connector.
>> In any case, I agree that this rule is spotted several times in the
>> most text and TextLint users might feel reluctant to look into it.
>> We have planned to look into it.
>> But in many cases it has been quite useful for me.
>>
>
> Thanks for the explanantion Jorge.
>
> Mariano
>
>>
>> Cheers,
>>
>> On Thu, Sep 23, 2010 at 4:14 PM, Mariano Martinez Peck
>> wrote:
>> > OkI am using TextLint for all my papers now :)
>> >
>> > Few more things:
>> >
>> > 1) It would be awesome a rule that detects duplication of connectors in
>> > a
>> > near area. For example, if I use connectors like "However, Nevertheless,
>> > Hence, On the contrary, One the other hand, etc..." it would be nice a
>> > rule
>> > that detects that you already use the same connector some lines
>> > before/after
>> > a specific one...
>> >
>> > 2) I don't understand the rule: "Do not join sentences with commas ".
>> > Is
>> > this working well ? I have these phrases for example:
>> >
>> >
>> > - To support automatic memory management, most object oriented systems
>> > are
>> > based on garbage collectors (GC) \cite{Jone96a}.
>> >
>> > - In class-based object-oriented languages, information about class
>> > usage is
>> > needed.
>> >
>> > - For this we use Distribution Map, a visualization showing spread and
>> > focus
>> > of properties across systems.
>> >
>> > I think the "comma" there are correct. Maybe I am wrong.
>> >
>> > Thanks
>> >
>> > mariano
>> >
>> >
>> > On Thu, Sep 2, 2010 at 9:34 PM, Mariano Martinez Peck
>> > wrote:
>> >>
>> >>
>> >> On Thu, Sep 2, 2010 at 9:20 PM, Jorge Ressia
>> >> wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> So
>> >>
>> >> I have just sent you by private email the .tex.
>> >>
>> >>>
>> >>> 1) Could not reproduce
>> >>>
>> >>
&g
Re: [Pharo-project] TextLint questions and feedback
Hi Mariano,
We are very happy that you found TextLint that useful. As you might
have noticed we fixed several of your reported issues and we are still
working on the remaining ones.
1.- Not difficult. Could you specify how this rule would work? how
many sentences should we take into account? Perhaps a whole paragraph.
You might find the rule TLWordRepetitionInParagraphRule, which is
already in TextLint useful, it detects the repetition of words in a
paragraphs. If the Word is used more than 3 times then the rule fails.
This will include the connectors that you mentioned. If you required a
repetition rule a little more strict you can always use this rule as a
basis for defining your new rule. We will be more that happy to
integrate it :)
2.- The objective behind "Do not join sentences with commas " is
simplicity. If you have a sentence with a single comma you might be
expressing two different things and divide them in two sentences might
be good. On the other hand, if you still want to keep your sentence
together this rule might signal that it might be a way of avoiding the
use of the coma and using some meaningful connector.
In any case, I agree that this rule is spotted several times in the
most text and TextLint users might feel reluctant to look into it.
We have planned to look into it.
But in many cases it has been quite useful for me.
Cheers,
On Thu, Sep 23, 2010 at 4:14 PM, Mariano Martinez Peck
wrote:
> OkI am using TextLint for all my papers now :)
>
> Few more things:
>
> 1) It would be awesome a rule that detects duplication of connectors in a
> near area. For example, if I use connectors like "However, Nevertheless,
> Hence, On the contrary, One the other hand, etc..." it would be nice a rule
> that detects that you already use the same connector some lines before/after
> a specific one...
>
> 2) I don't understand the rule: "Do not join sentences with commas ". Is
> this working well ? I have these phrases for example:
>
>
> - To support automatic memory management, most object oriented systems are
> based on garbage collectors (GC) \cite{Jone96a}.
>
> - In class-based object-oriented languages, information about class usage is
> needed.
>
> - For this we use Distribution Map, a visualization showing spread and focus
> of properties across systems.
>
> I think the "comma" there are correct. Maybe I am wrong.
>
> Thanks
>
> mariano
>
>
> On Thu, Sep 2, 2010 at 9:34 PM, Mariano Martinez Peck
> wrote:
>>
>>
>> On Thu, Sep 2, 2010 at 9:20 PM, Jorge Ressia
>> wrote:
>>>
>>> Hi,
>>>
>>> So
>>
>> I have just sent you by private email the .tex.
>>
>>>
>>> 1) Could not reproduce
>>>
>>
>> Should be reproducable with my .tex
>>
>>>
>>> 2)
>>> 2.a) Working on that
>>> 2.b) Could not reproduce
>>>
>>
>> me neither. Did you check if you are using a Set for the collection?
>>
>>>
>>> 3) It is hard to achieve, we still have it in the todo list.
>>
>> Yes, I imagined ;)
>>
>>>
>>> 4) Could not reproduce
>>>
>>
>> Should be reproducable with my .tex
>>
>>>
>>> 5) Fixed
>>>
>>> 6) Checking
>>>
>>
>> excellent :)
>>
>>>
>>> It would be cool if we could have a look at your file so we can have a
>>> better way of debugging these issues.
>>>
>>
>> Done :)
>>
>>>
>>> Thanks
>>>
>>>
>>>
>>> On Thu, Sep 2, 2010 at 6:54 PM, Jorge Ressia
>>> wrote:
>>> > Hi Mariano,
>>> >
>>> > Thanks for trying TextLint out and for the feedback.
>>> >
>>> > We will look into your issues and try to figure out a solution.
>>> >
>>> > If you have a draft of your text with these occurrences please send it
>>> > to us. You can remove the text that is not relevant.
>>> >
>>> > Cheers,
>>> >
>>> > Jorge
>>> >
>>> > 2010/9/2 Mariano Martinez Peck :
>>> >> Hi. First, please let me know if this is the correct place to talk
>>> >> about
>>> >> TextLint. I've just used for one paper I am writing and I have some
>>> >> questions/feedback. I am using the one click image.
>>> >>
>>> >> 1) The "An Rule" could be a little more smart and detects commands.
>>> >> For
>>> >> example, in my latex I have " an \emph{inner object}" and that was
&
Re: [Pharo-project] [squeak-dev] ESUG Awards
Hi Noury, It seems that the survey is already closed. Is this ok? Cheers, On Wed, Sep 15, 2010 at 10:17 AM, Noury Bouraqadi wrote: > Hi, > > This evening we'll announce the winners for the Tech Awards, and the Book > Awards. > For the Tech Awards, the conference participants did voted monday after the > demos. > For the Book Awards, you still can vote on-line untill 12pm (Barcelona Time). > http://www.surveymonkey.com/s/Q2LKKDT > > Best, > Noury @ ESUG 2010 - Barcelona :-) > --- > 18th International Smalltalk Joint Conference, September 13 -17 2010 > Barcelona, Spain. > http://www.esug.org/Conferences/2010 > > > > > -- Jorge Ressia www.jorgeressia.com ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] TextLint questions and feedback
Hi,
So
1) Could not reproduce
2)
2.a) Working on that
2.b) Could not reproduce
3) It is hard to achieve, we still have it in the todo list.
4) Could not reproduce
5) Fixed
6) Checking
It would be cool if we could have a look at your file so we can have a
better way of debugging these issues.
Thanks
On Thu, Sep 2, 2010 at 6:54 PM, Jorge Ressia wrote:
> Hi Mariano,
>
> Thanks for trying TextLint out and for the feedback.
>
> We will look into your issues and try to figure out a solution.
>
> If you have a draft of your text with these occurrences please send it
> to us. You can remove the text that is not relevant.
>
> Cheers,
>
> Jorge
>
> 2010/9/2 Mariano Martinez Peck :
>> Hi. First, please let me know if this is the correct place to talk about
>> TextLint. I've just used for one paper I am writing and I have some
>> questions/feedback. I am using the one click image.
>>
>> 1) The "An Rule" could be a little more smart and detects commands. For
>> example, in my latex I have " an \emph{inner object}" and that was detected
>> by the rule, althought I shouldn't. So...detecting the slash and ignore what
>> it surrounded by {} would be nice for this rule.
>>
>> 2) When I edit the code inside TextLint and I save it, two bad things
>> happens:
>> 2.a) I lost focus of the text, as it moves when it finishing saving.
>> The line I edited goes to the end of the text area. It would be great if
>> nothing moves nor to loose focus when saving.
>> 2.b) sometimes (I cannot reproduce) the order of the rules
>> changes...and this is not good because I was going in order, one by one, and
>> suddenly they are re-ordered. Maybe you are using a Set for that? using a
>> simple OrderedCollection could help.
>>
>> 3) If you edit the text (and it differs in the amount of characters), and DO
>> NOT save it, the following color highlighting are moved. It seems you keep
>> the position in the file, and until it is saved, rules results are pointing
>> to "unupdated" file. Of course, when I save the file, they are correct. I
>> guess this is from a performance point of view, but maybe you have a little
>> hack to do and make it better.
>>
>> 4) The rule "no white space before punctuation mark" showed me things I
>> didn't understand. For example, it says this line there is a "," (comma) :
>>
>> \item[ Shared object ] In the case of the \emph{shared objects}, it is
>> almost the same as in the \emph{inner objects}. An .
>
>
>> 5) Rules comments clearer. For example, when you say "Avoid using a lot, it
>> weakens the sentence" It would be better to put "Avoid using "a lot", it
>> weakens the sentence"
>> or "Avoid using *a lot*, it weakens the sentence"
>> or something to clearly mark the words not to use. Because sometimes the
>> words are confused with the context. Or this one:
>>
>> "After an only words beginning with a vowel are allowed. "
>> should be "After "an" only words beginning with a vowel are allowed."
>>
>> 6) For the rules of long sentences/paragraph it would be nice to ignore
>> \fotenote{}
>>
>> 7) Maybe this link is of interest for you:
>> http://matt.might.net/articles/shell-scripts-for-passive-voice-weasel-words-duplicates/
>>
>> Apart from all these things, the tool is very useful and I like it.
>>
>> thanks
>>
>> Mariano
>>
>>
>>
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Jorge Ressia
> www.jorgeressia.com
>
--
Jorge Ressia
www.jorgeressia.com
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] TextLint questions and feedback
Hi Mariano,
Thanks for trying TextLint out and for the feedback.
We will look into your issues and try to figure out a solution.
If you have a draft of your text with these occurrences please send it
to us. You can remove the text that is not relevant.
Cheers,
Jorge
2010/9/2 Mariano Martinez Peck :
> Hi. First, please let me know if this is the correct place to talk about
> TextLint. I've just used for one paper I am writing and I have some
> questions/feedback. I am using the one click image.
>
> 1) The "An Rule" could be a little more smart and detects commands. For
> example, in my latex I have " an \emph{inner object}" and that was detected
> by the rule, althought I shouldn't. So...detecting the slash and ignore what
> it surrounded by {} would be nice for this rule.
>
> 2) When I edit the code inside TextLint and I save it, two bad things
> happens:
> 2.a) I lost focus of the text, as it moves when it finishing saving.
> The line I edited goes to the end of the text area. It would be great if
> nothing moves nor to loose focus when saving.
> 2.b) sometimes (I cannot reproduce) the order of the rules
> changes...and this is not good because I was going in order, one by one, and
> suddenly they are re-ordered. Maybe you are using a Set for that? using a
> simple OrderedCollection could help.
>
> 3) If you edit the text (and it differs in the amount of characters), and DO
> NOT save it, the following color highlighting are moved. It seems you keep
> the position in the file, and until it is saved, rules results are pointing
> to "unupdated" file. Of course, when I save the file, they are correct. I
> guess this is from a performance point of view, but maybe you have a little
> hack to do and make it better.
>
> 4) The rule "no white space before punctuation mark" showed me things I
> didn't understand. For example, it says this line there is a "," (comma) :
>
> \item[ Shared object ] In the case of the \emph{shared objects}, it is
> almost the same as in the \emph{inner objects}. An .
> 5) Rules comments clearer. For example, when you say "Avoid using a lot, it
> weakens the sentence" It would be better to put "Avoid using "a lot", it
> weakens the sentence"
> or "Avoid using *a lot*, it weakens the sentence"
> or something to clearly mark the words not to use. Because sometimes the
> words are confused with the context. Or this one:
>
> "After an only words beginning with a vowel are allowed. "
> should be "After "an" only words beginning with a vowel are allowed."
>
> 6) For the rules of long sentences/paragraph it would be nice to ignore
> \fotenote{}
>
> 7) Maybe this link is of interest for you:
> http://matt.might.net/articles/shell-scripts-for-passive-voice-weasel-words-duplicates/
>
> Apart from all these things, the tool is very useful and I like it.
>
> thanks
>
> Mariano
>
>
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
--
Jorge Ressia
www.jorgeressia.com
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] class API question
Yep, It would be much better to sell out the names. On Fri, Aug 27, 2010 at 11:53 AM, Lukas Renggli wrote: > I think it would be beneficial to adapt the protocol of the refactoring > browser. > > It especially spells out all the names: > > #addInstanceVariable: > #allInstanceVariableNames > #instanceVariableNames > > Lukas > > On 27 August 2010 11:50, Stéphane Ducasse wrote: >> done :) >> I could not let that like that. >> >> Stef >> >> On Aug 27, 2010, at 11:11 AM, Marcus Denker wrote: >> >>> >>> On Aug 27, 2010, at 11:02 AM, Stéphane Ducasse wrote: >>> >>>> We are not consistent: >>>> >>>> do we want >>>> renameInstVar:to: >>>> or >>>> removeInstVarName: >>>> I prefer that. >>>> >>>> We have addInstVarName: >>>> -> should be addInstVarNamed: from my taste >>>> >>>> >>>> Now we want to have first class instance variable in the near future so I >>>> would like to have >>>> >>>> addInstVar: aVariable >>>> addInstVarNamed: aString >>>> >>>> What do you think? >>>> >>> >>> Yes! >>> >>> >>> -- >>> Marcus Denker -- http://www.marcusdenker.de >>> INRIA Lille -- Nord Europe. Team RMoD. >>> >>> >>> ___ >>> Pharo-project mailing list >>> Pharo-project@lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@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@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Jorge Ressia www.jorgeressia.com ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] ISSUE 2514
Hi, Thanks Fernando! Adrian, Stef this is the fix required for fixing one of the remanning failing tests in Pharo 1.1 Cheers, Jorge On Sun, Jun 6, 2010 at 4:28 PM, Fernando olivero wrote: > SLICE-NewTextMorph-acceptContents-FernandoOlivero.1 > > > > ISSUE 2514 > NewTextMorph does not accept on cmd-s. > NewTextMorph>>example1 is not working. > > Fixed this issue, made a test and aslo fixed #testFittingParagraph > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About TDD and Pharo
I've been using TDDFacilities in Pharo since it was first released. It is precisely what I needed to achieve real TDD while developing my tools. New features in the New Compiler and TextLint (from scratch) were developed using this tool. Doru, if you want I can give you a short demo of it. I think that what Hernan is proposing is very important. The debugger is the tool that TDD developers use the most, we should concentrate on it first and then try to find out other potential improvements in other tools. I think we should invest some time into this. Cheers, Jorge On Fri, Jun 4, 2010 at 7:36 AM, Lukas Renggli wrote: > OBSUnitIntegration is already providing some of those: > >> 1) When you are in the browser writing a test method, you can press ctrl + t >> to save the method and run the test. If the test runs, it will show the >> green dot in the browser, if it does not, it popups the debugger directly on >> the error. So, this is a way to avoid pressing ctrl + s (save) then going to >> the method list, rigth click an select run test and if it fails select that >> you want to debug it. > > Ctrl+T does not save, but it runs the tests and shows the debugger. I > don't think that I like the two things to be combined :-) > >> 2) Same as ctrl + t but ctrl + r to directly debug the test. It saves the >> method, puts a breakpoint in it and debugs it. Unfortunaly, in Pharo >> breakpoints dont show very well in the debuger (it highlights incorrect >> collaborations) > > Ctrl+D opens a full debugger on the first line of the selected test, > no matter if the test fails or not. It doesn't use breakpoints. And I > use it all the time :-) > > So maybe we could combine some of that code? > > Lukas > > > -- > Lukas Renggli > www.lukas-renggli.ch > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About long tests.
Sorry Stef, couldn't resist :) Now there is a distinction between unit tests and the rest of them. Unit tests are depicted as fast and model oriented tests. Later we will have to introduce more kinds of test for enriching our build and development process, tests like functional, architectural, lint, etc. 6942 unit tests run in 34 secs instead than 2:25 min running all tests. I think this will encourage developers to run the tests a little more often. I implemented a fix in the next slice. Name: SLICE-FastAndSlowTestDisociation-JorgeRessia.1 Author: JorgeRessia Time: 16 March 2010, 8:50:41 pm UUID: 9c44289b-bccb-4198-9a98-6dd9979e9bdd Ancestors: Dependencies: Gofer-Tests-JorgeRessia.117, KernelTests-JorgeRessia.164, SUnit-JorgeRessia.86, SUnitGUI-JorgeRessia.45, Tests-JorgeRessia.48 Test cases now answer the message isUnitTest in order to differentiate the unit test from the rest of the tests. - The tests that take too long are no more considered unit tests. - Some test were functional test so there are not considered unit tests. - The TestRunner was modified. A new menu entry can be found in the class pane for selecting all unit tests. Some more fixes here: Name: SLICE-FastAndSlowTestDisociation-JorgeRessia.2 Author: JorgeRessia Time: 16 March 2010, 8:58:11 pm UUID: 86461af2-534b-4091-8f2e-973b650db098 Ancestors: SLICE-FastAndSlowTestDisociation-JorgeRessia.1 Dependencies: Gofer-Tests-JorgeRessia.117, KernelTests-JorgeRessia.164, SUnit-JorgeRessia.87, SUnitGUI-JorgeRessia.45, Tests-JorgeRessia.48 - test fixed Cheers, Jorge On Tue, Mar 16, 2010 at 3:18 PM, Stéphane Ducasse wrote: > focus on the paper jorge coding only for the fun :) > We have time. > > Stef > > On Mar 16, 2010, at 9:35 AM, Jorge Ressia wrote: > >> Hi, >> >> No, I have to finish that. Is still in my todo list. >> I'll try to make some time today to look into that. >> >> Cheers, >> >> Jorge >> >> On Tue, Mar 16, 2010 at 9:32 AM, Adrian Lienhard wrote: >>> Yes, it would be very good to have faster tests. In my experience, if tests >>> take too long to run, you don't use them. >>> >>> During the sprint in Lille, Jorge started to sort out long running tests >>> from the rest and make them subclass from SlowTestCase (or something >>> similar). >>> >>> Cheers, >>> Adrian >>> >>> >>> On Mar 16, 2010, at 09:13 , Lukas Renggli wrote: >>> >>>> Btw, I am running the Pharo tests in my builds now too: >>>> >>>> >>>> http://hudson.lukas-renggli.ch/job/Pharo/lastCompletedBuild/testReport/(root)/ >>>> >>>> Click on duration twice to see the tests sorted by run-time. I feel a >>>> bit bad that the slowest test case is one that I wrote. I'll see if I >>>> can speed that up some more. >>>> >>>> Lukas >>>> >>>> On 15 March 2010 20:56, stephane ducasse wrote: >>>>> Hi jorge >>>>> >>>>> did you publish the cleans for the tests you did during the sprint? >>>>> >>>>> Thanks Stef >>>>> >>>>> ___ >>>>> Pharo-project mailing list >>>>> Pharo-project@lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> >>>> >>>> -- >>>> Lukas Renggli >>>> http://www.lukas-renggli.ch >>>> >>>> ___ >>>> Pharo-project mailing list >>>> Pharo-project@lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> ___ >>> Pharo-project mailing list >>> Pharo-project@lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About long tests.
Hi, No, I have to finish that. Is still in my todo list. I'll try to make some time today to look into that. Cheers, Jorge On Tue, Mar 16, 2010 at 9:32 AM, Adrian Lienhard wrote: > Yes, it would be very good to have faster tests. In my experience, if tests > take too long to run, you don't use them. > > During the sprint in Lille, Jorge started to sort out long running tests from > the rest and make them subclass from SlowTestCase (or something similar). > > Cheers, > Adrian > > > On Mar 16, 2010, at 09:13 , Lukas Renggli wrote: > >> Btw, I am running the Pharo tests in my builds now too: >> >> >> http://hudson.lukas-renggli.ch/job/Pharo/lastCompletedBuild/testReport/(root)/ >> >> Click on duration twice to see the tests sorted by run-time. I feel a >> bit bad that the slowest test case is one that I wrote. I'll see if I >> can speed that up some more. >> >> Lukas >> >> On 15 March 2010 20:56, stephane ducasse wrote: >>> Hi jorge >>> >>> did you publish the cleans for the tests you did during the sprint? >>> >>> Thanks Stef >>> >>> ___ >>> Pharo-project mailing list >>> Pharo-project@lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Issue 2140 - Packages dirty after running the tests
Hi, When running tests, Changes are being applied to the system and Packages are left dirty. Some of these issues have been solved in Name: Tests-JorgeRessia.128 Author: JorgeRessia Time: 13 March 2010, 2:39:13 pm UUID: ae807242-d429-497f-916d-8d53aeffe87a Ancestors: Tests-JorgeRessia.127 - Executing Compilation test silently - ATestCase in Tests-Traits created a class, now is done silently - In ChangeSetClass a DeleteMe package was created and the PackageOrganizer and the MCWorkingCopy were dirty. Now the package is deleted. Issues still remain to be fixed in: - Tests-Traits - Tests-Monticello - Tests-PrimCallController - Tests-SystemChangeNotifier Cheers, Jorge ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Issue 2030 - fixed
Hi, The shadowing was detected by the Encoder>>bindTemp: for method added by Traits. A new validation was added for detecting this special case and avoid the error. Name: SLICE-ShadowingOfTraitsIssue2030-JorgeRessia.2 Author: JorgeRessia Time: 13 March 2010, 4:34:47 pm UUID: b7513eee-36ef-4fac-b976-9169e7d94c1c Ancestors: SLICE-ShadowingOfTraitsIssue2030-JorgeRessia.1 Dependencies: Compiler-JorgeRessia.194, Tests-JorgeRessia.129 Cheers, Jorge ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [update 1.1] #11243
Hi Adrian, Sorry for the delay, too many things today. Ok, I added 17 test to Tests-Compiler which model the cases of shadowing, at least the ones I could come up with. I also modified the Encoder>>bindTemp: in order to make it a little bit more intention revealing. My changes are in: Compiler-JorgeRessia.144 Tests-JorgeRessia.46 Some comments: - In order to test the not interactive mode I had to mock the Transcript. I could not find a better solution, if anybody has a better one just let me know I'll change it. - There is a special case which is that when you are NOT in interactive mode if the shadowed variable is a temp then the syntax error is triggered as in interactive mode. This is the behavior implemented before I did the changes. Is that what we want? - I added this test to Tests-Compiler package, I would have preferred to add them to Compiler-Tests but there was nothing there. Cheers, Jorge On Thu, Mar 4, 2010 at 8:45 PM, Adrian Lienhard wrote: > Hi Jorge, > > Just let me know when you think the code is ok for 1.0 or when you have > something different that I should integrate. Thanks! > > Cheers, > Adrian > > On Mar 4, 2010, at 09:37 , Jorge Ressia wrote: > >> Hi Adrian, >> >> Yep, I have the same problem as you. My idea was to make it work as >> before without completely changing it. Basically because I did not >> have the test support to validate my changes. >> Anyhow, what I propose is to write a bunch of tests for every case >> that we know and then if new cases show up add them to the test suite. >> And then play with the code. >> >> I will work on that today, is that ok? >> >> For the explanation of what is going on is that now node can be an >> instance variable node, then the behavior that was there was not >> appropriate in the sense that instance variable nodes do not >> understand #scope. >> However, why this validation "(node isTemp or: [requestor >> interactive])" was there in the first place is not that clear to me, >> but it's been there since 1999. >> >> I'll try to build the tests and come up with a better solution. >> >> Cheers, >> >> Jorge >> >> On Thu, Mar 4, 2010 at 9:14 AM, Adrian Lienhard wrote: >>> Jorge, >>> >>> I looked at the code to integrate in 1.0. And I really have troubles >>> understanding it (even after drawing a boolean table for the different >>> combinations of or: ifTrue: and: ifFalse:). Is it correct that the warning >>> is shown when node isTemp is false and requestor interactive is true? Is >>> the comment still accurate? >>> >>> This is the code: >>> >>> "When non-interactive raise the error only if its a duplicate" >>> (node isTemp or: [requestor interactive]) >>> ifTrue:[ ((node isTemp) and: [node scope <= 0] ) >>> ifFalse: [^self notify:'Name is >>> already defined' ]] >>> >>> Cheers, >>> Adrian >>> >>> On Mar 3, 2010, at 20:47 , Stéphane Ducasse wrote: >>> >>>> 11243 >>>> - >>>> >>>> - Issue 2102: Fix the fact that local temp can shadow silently instance >>>> var --- fixed >>>> Problem fixed: >>>> We cannot have twice the same block arg in a method >>>> >>>> [:each | each ...] >>>> [:each | each ...] >>>> >>>> THANKS jorge :) >>>> Do you like good bio beer? >>>> >>>> Stef >>>> >>>> >>>> ___ >>>> Pharo-project mailing list >>>> Pharo-project@lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> ___ >>> Pharo-project mailing list >>> Pharo-project@lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [update 1.1] #11243
Hi, Sure - We need a way of testing the New compiler, It is very hard to now if the changes I am introducing work. I have a set of test but they are mainly oriented towards the closure implementation. - Not everything is done with visitors. - The ASTTranslator and subclasses have methods of considerable size which are hard to understand, mainly the emits and accepts - The Decompiler does not work - IRTranslator: needs some work, there are some abstractions that are not clear like sequences and pending instructions which make the code in every other method more complicated. - It is not completely modular, we do not have a way of configuring it from scratch - The phases of the compiler are not clearly defined If you ask me, I would say that the key point is to have a way of validating our compiler. This is what is holding me back from introducing more aggressive refactorings. This does not mean that we need all those point in order to have a running compiler, on the contrary, the compiler is working quite well, I am fixing special cases right now. But, if we what something we could improve and experiment with, we will need these points. Cheers, Jorge On Thu, Mar 4, 2010 at 1:16 PM, Stéphane Ducasse wrote: > jorge > > could you make a list of things to do in 10 min? > So that we get an idea. I really believe that we should invest for the future. > > Stef > > On Mar 4, 2010, at 10:07 AM, Jorge Ressia wrote: > >> Yes, the New compiler is not better. However, I think the New Compiler >> is the right direction to pursue. >> >> After fighting with it for some months to make the Closures work in it >> I can tell you that I learn a great deal from it, painfully :) . >> But I now have a pretty good idea of what it is required to have a >> modularized compiler with more suitable abstraction for this >> particular domain. >> I implemented many tests and I have to implement a lot more. Then, I >> believe that by expressing ourselves through these tests we will be >> able to modify the compiler to make it look the way we want. >> >> At least that is my plan with the New compiler. >> >> Cheers, >> >> Jorge >> >> On Thu, Mar 4, 2010 at 9:53 AM, Lukas Renggli wrote: >>>>> I'll try to build the tests and come up with a better solution. >>>> >>>> You what I would love to spend 2/3 weeks just coding in the new compiler >>>> and making sure >>>> that it has the right abstractions/messages to deal with issue like that. >>> >>> The problem is that the New Compiler is not really in a better state >>> than the old compiler. Of course it has more objects and is much >>> easier to extend, but all in all it is a mess too. This is mostly due >>> to the fact that the system below it changed quite a bit in the past >>> years (pragmas, properties, closures, primitives, new bytecodes, ...) >>> and that the New Compiler had to be patched and changed quite heavily >>> to accommodate these new requirements that it was not designed for. >>> Maintaining and fixing the New Compiler got so extremely expensive >>> that it is questionable if this is still a viable platform? Ask Jorge >>> and Marcus. >>> >>> Lukas >>> >>> -- >>> Lukas Renggli >>> http://www.lukas-renggli.ch >>> >>> ___ >>> Pharo-project mailing list >>> Pharo-project@lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [update 1.1] #11243
Yes, the New compiler is not better. However, I think the New Compiler is the right direction to pursue. After fighting with it for some months to make the Closures work in it I can tell you that I learn a great deal from it, painfully :) . But I now have a pretty good idea of what it is required to have a modularized compiler with more suitable abstraction for this particular domain. I implemented many tests and I have to implement a lot more. Then, I believe that by expressing ourselves through these tests we will be able to modify the compiler to make it look the way we want. At least that is my plan with the New compiler. Cheers, Jorge On Thu, Mar 4, 2010 at 9:53 AM, Lukas Renggli wrote: >>> I'll try to build the tests and come up with a better solution. >> >> You what I would love to spend 2/3 weeks just coding in the new compiler and >> making sure >> that it has the right abstractions/messages to deal with issue like that. > > The problem is that the New Compiler is not really in a better state > than the old compiler. Of course it has more objects and is much > easier to extend, but all in all it is a mess too. This is mostly due > to the fact that the system below it changed quite a bit in the past > years (pragmas, properties, closures, primitives, new bytecodes, ...) > and that the New Compiler had to be patched and changed quite heavily > to accommodate these new requirements that it was not designed for. > Maintaining and fixing the New Compiler got so extremely expensive > that it is questionable if this is still a viable platform? Ask Jorge > and Marcus. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [update 1.1] #11243
Hi Adrian, Yep, I have the same problem as you. My idea was to make it work as before without completely changing it. Basically because I did not have the test support to validate my changes. Anyhow, what I propose is to write a bunch of tests for every case that we know and then if new cases show up add them to the test suite. And then play with the code. I will work on that today, is that ok? For the explanation of what is going on is that now node can be an instance variable node, then the behavior that was there was not appropriate in the sense that instance variable nodes do not understand #scope. However, why this validation "(node isTemp or: [requestor interactive])" was there in the first place is not that clear to me, but it's been there since 1999. I'll try to build the tests and come up with a better solution. Cheers, Jorge On Thu, Mar 4, 2010 at 9:14 AM, Adrian Lienhard wrote: > Jorge, > > I looked at the code to integrate in 1.0. And I really have troubles > understanding it (even after drawing a boolean table for the different > combinations of or: ifTrue: and: ifFalse:). Is it correct that the warning is > shown when node isTemp is false and requestor interactive is true? Is the > comment still accurate? > > This is the code: > > "When non-interactive raise the error only if its a duplicate" > (node isTemp or: [requestor interactive]) > ifTrue:[ ((node isTemp) and: [node scope <= 0] ) > ifFalse: [^self notify:'Name is > already defined' ]] > > Cheers, > Adrian > > On Mar 3, 2010, at 20:47 , Stéphane Ducasse wrote: > >> 11243 >> - >> >> - Issue 2102: Fix the fact that local temp can shadow silently instance var >> --- fixed >> Problem fixed: >> We cannot have twice the same block arg in a method >> >> [:each | each ...] >> [:each | each ...] >> >> THANKS jorge :) >> Do you like good bio beer? >> >> Stef >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Undo compiler temporary variable handling
Fixed in Compiler-JorgeRessia.142 The behavior should be the same as before removing the interactive validation. I recompiled the image and it worked fine. Lukas tried it out with some monticello test packages and worked too. Cheers, Jorge On Wed, Mar 3, 2010 at 6:34 PM, Stéphane Ducasse wrote: > Yanni > > I imagine that you are right. > Jorge I got problem with > > colorPaletteForDepth: depth extent: chartExtent > > I think that we should recompile the image. I should have thought about that. > I could remove the last change for the moment. > > Stef > > On Mar 3, 2010, at 4:58 PM, Yanni Chiu wrote: > >> Jorge Ressia wrote: >>> We tested it with Lukas and is working fine. However, we should see >>> that there are no further side effects. >> >> I can't check right now, but I suspect it is the cause of this >> side-effect - you cannot use the same block variable name in the same >> method. E.g. >> >> foobar >> collectionA do: [:each | each foo]. >> collectionB do: [:each | each bar]. >> >> I get a syntax error on the second "each". Is this considered shadowing? >> >> -- >> Yanni >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Undo compiler temporary variable handling
Hi, I committed the change Compiler-JorgeRessia.141 Basically the problem was that the interactive mode was not taken into account in the Encode and BytecodeEncoder >> bindTemp: method. bindTemp: name "Declare a temporary; error not if a field or class variable or out-of-scope temp. Read the comment in Encoder>>bindBlockArg:within: and subclass implementations." self supportsClosureOpcodes ifFalse: [^super bindTemp: name]. scopeTable at: name ifPresent: [:node| "When non-interactive raise the error only if it is a duplicate" (node isTemp or: [requestor interactive]) ifTrue:[^self notify:'Name is already defined'] ifFalse:[self warnAboutShadowed: name]]. ^self reallyBind: name We tested it with Lukas and is working fine. However, we should see that there are no further side effects. Cheers, Jorge On Wed, Mar 3, 2010 at 9:37 AM, Stéphane Ducasse wrote: > lukas can youreread because I tried to improve thte explanation. > > >> In 1.1 and I think that this is the wrong version of the changes that was >> introduced >> because the interface sucks >> = >> Parser warningAllowed: true >> >> Object subclass: #Zork >> instanceVariableNames: 't' >> >> zork >> >> | t | >> t := 1. >> >> I get "t appears to beunused in this method.Ok to remove it?" >> >> Now with >> Parser warningAllowed: false >> >> Object subclass: #Zork >> instanceVariableNames: 't' >> >> zork >> >> | t | >> t := 1. >> the variable t shadows the instance variable without noticed >> >> So for Pharo we get simply for now issue Parser warningAllowed: true >> to get it to the "normal" behavior. >> >> In 1.0 >> = >> The interface changes -> Parser warnUser >> but we have the same silly broken pop up. >> >> Now I checked and in 3.9 >> = >> >> we got 'Name is already defined.' which is the correct behavior >> so it seems that this is not the warning preference that are responsible of >> the problem. > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Continuous Integration Server for Pharo?
Hi,
I am currently working with Diego Kogan on the Continuous Integration
Server for pharo. We will be working heavily the comming two weeks in
order to finish the implementation of the basic requirements. Our case
studies will be Moose and Seaside.
We expect ot have a running version for mid december.
Cheers,
Jorge
On Sun, Nov 29, 2009 at 7:53 AM, Stéphane Ducasse
wrote:
> Hi bart
>
> we use some scripts (developed at netstyle)
> and ESUG will support hernan student to develop one. I know that Jorge
> started also and should work with them.
> So we should join forces.
> The idea is that the server should be able to load metacello configuration.
> Jorge/Hernan/Simon
> - what is the status
> - how could we join forces?
>
> Stef
>
>
> On Nov 28, 2009, at 1:23 PM, Bart Gauquie wrote:
>
>> Dear all,
>>
>> I come from a Java world and there we use for instance :
>> http://hudson-ci.org/ to do a continuous integration build. Which means all
>> latest code gets updated, all test ran & if build successful, the code is
>> tagged (so you can take the code again from a successful build). It also
>> provides a nice GUI, and lets you inspect previous builds, the results from
>> that build, ... .
>>
>> In Pharo, I did not directly find an alternative, and therefor, also as an
>> exercise, I tried to build one myself.
>> The primitive, but working result so far is:
>> http://www.squeaksource.com/BuildBot.
>>
>> This project depends on BBProjectDescription, which defines class
>> BBBuildProjectDescription with defines:
>> • BBBuildProjectDescription>>allProjectPackageNames
>> • BBBuildProjectDescription>>installLatestWithDependencies
>> • BBBuildProjectDescription>>buildsClassToPutVersionsOn
>> What buildbot then does is using a BBBuildProjectDescription , checkout all
>> latest code, run the tests for all these packages & , if successfull, take
>> the buildsClassToPutVersionsOn and add a new method on it, describing the
>> exact package numbers :
>> for instance:
>> BuildBotMockProjectBuilds class >> packagesForBuild20091127102654
>> ^#(('TODO' -> 'TODO-BKBAG.5.mcz') ('BuildBtMockProject' ->
>> 'BuildBtMockProject-BartGauquie.7.mcz') ).
>>
>> Using this information I can easily install this exact version. Furthermore
>> creating a release is then just creating for instance a class
>> BuildBotMockProjectReleases with:
>> BuildBotMockProjectReleasesclass >> release_1_0
>> ^BuildBotMockProjectBuilds packagesForBuild20091127102654
>>
>> I am in fact 'tagging' a group packages that belong together and work
>> together. So I can rollout this exact versions of the packages to some image
>> automatically.
>>
>>
>> However,
>> Today I noticed that there already existed a project:
>> http://www.squeaksource.com/TestServerSimple which more or less does the
>> same thing. The only thing it does not do, or I did not find it, is to
>> version the build, so that you can restore a project again ; a project which
>> is consisting of a number of packages which are compatible and for which all
>> tests ran. Is there a way to do that in TestServerSimple?
>>
>> Furthermore, are there any other projects that do a similar thing I'm not
>> aware of? Is there any default way in Pharo to build a project which
>> consists of multiple packages that each have different versions?
>>
>> I've seen MetaCello & Gofer as some other way 2 load groups of packages, but
>> no integration into some kind of ci tool.
>>
>> This kind of automated ci server seems 2 me an essential tool in Pharo.
>>
>> Thanks for any pointers / ideas !
>>
>> Kind Regards,
>>
>> Bart
>>
>> --
>> imagination is more important than knowledge - Albert Einstein
>> Logic will get you from A to B. Imagination will take you everywhere -
>> Albert Einstein
>> Learn from yesterday, live for today, hope for tomorrow. The important thing
>> is not to stop questioning. - Albert Einstein
>> The true sign of intelligence is not knowledge but imagination. - Albert
>> Einstein
>> Gravitation is not responsible for people falling in love. - Albert Einstein
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] New Compiler
Hi, Marcus Denker and myself will be working on the New Compiler for Pharo. We have a plan draft of the steps that need to be followed in order to get it up and running in Pharo: 1.- Write good tests for each module parse, check, codeGen, execute and check if works. First simple example, and then complex ones. Test recompilation too. 2.- Performance, how long does it take compared to the old compiler. 3.- Error messages: at least like in the old compiler. 4.- Introduce Eliot's Closures. Soon we will have a more detailed and formal list of thing to be done. Cheers, Jorge Ressia ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
