Re: [Pharo-project] how to control the native window size and position
Pretty cool! Thanks a lot. Cheers, Doru On 31 Jan 2011, at 17:17, Gary Chambers wrote: Slightly evil but this works on Windows (hopefully for Mac too!)... HostWindowProxy new instVarNamed: #windowHandle put: 1; windowPosition: 0 @ 0; windowSize: 800 @ 600; windowTitle: 'Screencast' Regards, Gary - Original Message - From: Tudor Girba tudor.gi...@gmail.com To: Pharo-project@lists.gforge.inria.fr Development pharo-project@lists.gforge.inria.fr Sent: Monday, January 31, 2011 3:10 PM Subject: [Pharo-project] how to control the native window size and position Hi, Is there a way to control the size and screen position of the parent window? I would need this for controlling the size of screencasts. I am particularly interested in a solution for Mac. Cheers, Doru -- www.tudorgirba.com Some battles are better lost than fought. -- www.tudorgirba.com Obvious things are difficult to teach.
Re: [Pharo-project] About KeyBindings
Hi Fernando, Sounds nice. I would be interested in having a bindings-per-morph solution. Cheers, Doru On 31 Jan 2011, at 16:18, Fernando Olivero wrote: Hi, recently there were some discussion on implementing KeyBindings for our IDE. There are at least 3 frameworks which address this functionality, the last one mentioned is the work done by Guillermo. I've implemented another one, for Gaucho. From what i understand, the previous work focuses on implementing GLOBAL keybindings . Basically adding behavior to HandMorph or PasteUpMorph or the toolbar ( docking bar) present in the World. My implementation is a generic keybinding for any Morph, which can be applied to any morph. Special cases for the docking bar or the paste up Morph can be easily implemented following this uniform scheme. I didn't have the time to integrate it into Pharo yet, but will do in one week from now. I like to bring up the discussion on which one we should adopt and integrate into Morphic, points in favor of my approach: 1) clean 2) customizable 3) generic: no special cases I believe the other Global keybindings should be a subset of this generic keybinding mechanism. Fernando pd: From a previous mail: ... So for example, if you want to delete any Morph from the system by pressing cmd-w, you have to add the following binding: condition := GMCondition compositeWith: #( #understandsKeyBindingCommandCondition #uneditedCondition ) ). binding := GMKeyBinding actingOn: $w asciiValue modifiedBy: #(#command) satisfying: condition applying: #close. m := Morph new. m addKeyBinding: binding . ... pd2: Useful and related comment from Stef .. A classVar Binding and an instance var binding. **All** the methods only access binding binding get initialized with the default table defined in Binding = we can have table binding sharing = we can have instance based customization. -- www.tudorgirba.com Yesterday is a fact. Tomorrow is a possibility. Today is a challenge.
[Pharo-project] how to use dejavu bitmap fonts
Hi, I am trying to use the DejaVuBitmapFonts, but I do not know how to install them. I tried the following: Gofer it squeaksource: 'DejaVu'; package: 'DejaVuBitmapFonts'; load. DejaVuHolder installFull. However, this creates a problem in using TextConstants. Can anyone help? Cheers, Doru -- www.tudorgirba.com One cannot do more than one can do.
Re: [Pharo-project] how to use dejavu bitmap fonts
I took a look, but I do not know what to do :(. Can anyone else provide some more specific directions? Cheers, Doru On 31 Jan 2011, at 22:00, Stéphane Ducasse wrote: The package should be updated to 1.2. It should declare fonts probably in one of the classVar of the TextConstant SharedPool. Probably TextSharedInformation have a look. In 1.2 we cleaned the last global poolvar = textConstant which was used as a pool but also as a repository to plug anything inside instead of specific classVariable in adequate classes. It was a good plate of spaghettis code. I know that benjamin wants to take some times to do another pass and move the left over to the class they belongs to but it will take some time. Stef On Jan 31, 2011, at 9:52 PM, Tudor Girba wrote: Hi, I am trying to use the DejaVuBitmapFonts, but I do not know how to install them. I tried the following: Gofer it squeaksource: 'DejaVu'; package: 'DejaVuBitmapFonts'; load. DejaVuHolder installFull. However, this creates a problem in using TextConstants. Can anyone help? Cheers, Doru -- www.tudorgirba.com One cannot do more than one can do. -- www.tudorgirba.com In a world where everything is moving ever faster, one might have better chances to win by moving slower.
Re: [Pharo-project] pharo.st should be a permanent domain, I think
+1 Doru On 31 Jan 2011, at 22:24, Alexandre Bergel wrote: I agree with Adrian Alexandre Le 31 janv. 2011 à 15:31, Adrian Lienhard a...@netstyle.ch a écrit : -1 ...because in my opinion there should be exactly one main domain name. The additional names should just redirect to this one. Of course we could discuss whether pharo.st should be that main domain. But (already quite long time ago) we decided to go for pharo-project.org. I still think that is the better name, in particular for people who don't know what the meaning of .st is. I think they are less likely to klick on www.pharo.st in a search engine than on www.pharo-project.org. Cheers, Adrian On Jan 31, 2011, at 21:15 , Diogenes Moreira wrote: Always ready. as a boy scout.. only send me de ssh conxion... On Mon, Jan 31, 2011 at 5:08 PM, Esteban Lorenzano esteba...@gmail.comwrote: Hi, I tried pharo.st to reach pharo. I liked. It's small, concise, beautiful (and it has a .st!) One problem is that as soon as you type pharo.st, you loose the url. I would like to stay in the url I entered to pharo-project. I think this is easily doable with an apache configuration. I'm not an apache guy, but I'm sure if there are some problem with this, and all of you agree this is desirable, someone from the list (cough, cough, Diógenes, cough, cough) can do the job :) Cheers, Esteban -- www.tudorgirba.com Yesterday is a fact. Tomorrow is a possibility. Today is a challenge.
[Pharo-project] [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.
Re: [Pharo-project] Pharo fondation: administration and real people
Excellent news! I agree that the admin should be kept to a minimum. It would be good to define the role of the board from the start. One thing that is important is not just how people get in the board, but also how they go away. I would be interested in getting involved in the board, if wanted. Cheers, Doru On 3 Feb 2011, at 11:17, Stéphane Ducasse wrote: Hi guys we are filling up papers with luc to get a fondation for pharo. The idea there is to have a minimal administrative board: a president that signs and a tresaurer that counts. We suggest to be me and luc because he is doing the work for the bank ;) This admin board should be kept small else at each changes we have to sign papers and go to the prefecture and Now we want to have a real board and we would like to hear from you who we would like to have on the board. For me I would like to get people from industry: - adrian - johan then some acad - me - marcus - luc But we want to hear from you about ideas. We do not want an election because we do not want to have election :) The goal of the board will be to think and organize ***public*** discussions around pharo visions and next steps + organization of bounty and money collecting actions + infrastructure (paying bills for servers if necessary) + collect licenses... Stef -- www.tudorgirba.com To lead is not to demand things, it is to make them happen.
Re: [Pharo-project] Oh, great.. SqS is down
Thanks for the work, Marcus. It works fine now. Cheers, Doru On 3 Feb 2011, at 20:01, Marcus Denker wrote: On Feb 3, 2011, at 7:57 PM, Tudor Girba wrote: Hi, It looks like there was a problem: all commits I published over the past couple of days in moose and glamour are now missing from the repository. I did not check other one projects yet. Could there have been a mistake when restarting or are these lost? No idea... for sure *not* the files, they are written to disk and never deleted. Hmm. So maybe I did something wrong? Or there is a way to re-load missing files from disk? Cheers, Doru On 3 Feb 2011, at 19:04, Marcus Denker wrote: On Feb 3, 2011, at 6:30 PM, Levente Uzonyi wrote: On Thu, 3 Feb 2011, Marcus Denker wrote: On Feb 3, 2011, at 5:47 PM, Igor Stasenko wrote: so i can do home... (grrr) up again. I will give you the needed info to restart it yourself tomorrow. Wouldn't it be better to create a cron job which checks it every minute and restarts it if necessary? Yes! Another thing would be to just restart SqueakSource once per week. It sounds like a hack, but calling it rejuvenation makes it sound better :-) I suggested both in the past, but there was a reason why both where not done. But I don't remember... Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. -- www.tudorgirba.com What we can governs what we wish. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. -- www.tudorgirba.com Sometimes the best solution is not the best solution.
Re: [Pharo-project] About FS: sad reality.
Thanks, Max. I am sure that would help the situation. Cheers, Doru On 4 Feb 2011, at 18:09, Max Leske wrote: I'll try to give it a shot in the next two or three months if that's any comfort. Max On 04.02.2011, at 17:36, Stéphane Ducasse wrote: Hi guys I'm sorry but I stopped working on FS. I cannot guess what is private or not, what is the interface of this code. I spent my time guessing and guessing wrong. So I stop. Simple. In addition I will veto the integration of this code in this state to be added into pharo (sad I started to write an help but it is probably full of mistakes). I HATE undocumented code that tell me eveyr minutes that I'm a fucking idiot. Too bad I'm not smart enough. Now without decent comments (I mean more than a line in class comment when there is one) we cannot accept code. Sad but true. Good luck if you want to use it and improve it. Stef -- www.tudorgirba.com Speaking louder won't make the point worthier.
Re: [Pharo-project] Issue 3653 in pharo: enh: change cursor form when over active editable text morph
This is cool. Doru On 4 Feb 2011, at 21:31, ph...@googlecode.com wrote: Updates: Status: Closed Comment #2 on issue 3653 by stephane...@gmail.com: enh: change cursor form when over active editable text morph http://code.google.com/p/pharo/issues/detail?id=3653 in 13036 -- www.tudorgirba.com We cannot reach the flow of things unless we let go.
Re: [Pharo-project] [ANN] JNIPort 2.0 for VisualWorks, Pharo and Squeak
Sounds great! What are the impediments of getting it to work with Cog on Pharo? Cheers, Doru On 5 Feb 2011, at 16:14, Joachim Geidel wrote: JNIPort 2.0 for VisualWorks, Pharo and Squeak is now available! JNIPort is a Smalltalk library which allows Java code to be invoked from Smalltalk. It acts as a bridge between the world of Smalltalk objects and a Java Virtual Machine (JVM) where Java code is executing. For more information see http://jniport.wikispaces.com JNIPort 2.0 for VisualWorks can be loaded from the Cincom Public Store Repository and from the JNIPort wiki at http://jniport.wikispaces.com/Downloads JNIPort 2.0 for Pharo and Squeak is available from SqueakSource at http://www.squeaksource.com/JNIPort.html and from the JNIPort wiki. The changes from JNIPort 1.9 are: - JNIPort can now be used in Pharo and Squeak. - Packages have been renamed such that the can be shared between Store and Monticello. - Platform specific code has been moved to separate packages to make the core packages portable between VisualWorks, Pharo, and Squeak. - The much-critized _null postfix used for selectors of wrapper methods which don't have arguments is gone. - A few bugs have been fixed. Installation instructions for VisualWorks are on the JNIPort wiki, instructions for Pharo and Squeak are on the wiki of the JNIPort project page of SqueakSource. I strongly encourage you to read the instructions before installing and using JNIPort. JNIPort 2.0 has been tested with: - VisualWorks from 7.5 to 7.8 (trent dec10.3) on Mac OS X 10.6.6 and Windows XP SP 3 - VisualWorks from 7.7 to 7.8 (trent dec10.3) on Ubuntu 10.04 (64bit) with both the 32-bit and the 64-bit VisualWorks VMs - Squeak 4.2 on Mac OS X 10.6.6 and Windows XP SP 3 - Pharo 1.1.1 and 1.2 on Mac OS X 10.6.6 and Windows XP SP 3 Known issues: - In Pharo 1.1.1, you may encounter an error when JNIPort tries to register a new Java object in an internal weak dictionary. This is a bug in Pharo's implementation of this collection class. I can't do anything about it. If you can't live with it, please upgrade to Pharo 1.2. - JNIPort for Pharo and Squeak currently cannot be used with the Cog VM. - Callbacks from foreign operating system threads cannot be used in Pharo and Squeak. The Alien foreign function interface does not yet support this feature. When you run the unit tests, three tests will fail because of this restriction. These failures are expected and do not indicate bugs. Best regards, Joachim Geidel -- www.tudorgirba.com Don't give to get. Just give.
Re: [Pharo-project] new Cog VMs available
Thanks Eliot. And indeed, I subscribe to the below question as well :) Cheers, Doru On 7 Feb 2011, at 09:12, Francois Stephany wrote: Hi Eliot, Probably a stupid question but what's the difference between SimpleStackBasedCogit and StackToRegisterMappingCogit ? new Cog VMs are available, SimpleStackBasedCogit @ http://www.mirandabanda.org/files/Cog/VM/VM.r2359/ and StackToRegisterMappingCogit @ http://www.mirandabanda.org/files/Cog/VM/VM.r2361. I think the new code generator is ready for prime time now. I fixed a number of bugs over the past three weeks and we're now using the StackToRegisterMappingCogit internally at Teleplace. -- www.tudorgirba.com We are all great at making mistakes.
Re: [Pharo-project] new Cog VMs available
Thanks Francois for asking the questions for me :) Cheers, Doru On 7 Feb 2011, at 11:02, Francois Stephany wrote: Ok :) In practice which one the end user should use ? Are there any performance/stability difference ? Probably a stupid question but what's the difference between SimpleStackBasedCogit and c? SimpleStackBasedCogit maps values to machine registers when generating code, while stack-based one uses stack for everything. -- www.tudorgirba.com Problem solving efficiency grows with the abstractness level of problem understanding.
[Pharo-project] configuring shout programmatically
Hi, I am not sure what is the preferred way to set Shout programmatically. Can anyone point me to a script that already does that? I would be interested in proposing another color configuration and package it with the Glamorous Theme. Cheers, Doru -- www.tudorgirba.com No matter how many recipes we know, we still value a chef.
Re: [Pharo-project] configuring shout programmatically
black ) (externalCallTypePointerIndicator black ) (primitiveOrExternalCallStart black bold) (primitiveOrExternalCallEnd black bold ) (methodTempBar gray ) (blockTempBar gray ) (blockArgsBar gray ) (primitive (green muchDarker) bold) (pragmaKeyword (green muchDarker) bold) (pragmaUnary(green muchDarker) bold) (pragmaBinary (green muchDarker) bold) (externalFunctionCallingConvention (green muchDarker) bold) (module (green muchDarker) bold) (blockTempVar gray italic) (blockPatternTempVargray italic) (instVar black bold) (workspaceVar black bold) (undefinedIdentifierred bold) (incompleteIdentifier (gray darker) (italic underlined)) (tempVar (gray darker) italic) (patternTempVar (gray darker) italic) (poolConstant (gray darker) italic) (classVar (gray darker) bold) (globalVar black bold) ) #Luc 2011/2/7 Stéphane Ducasse stephane.duca...@inria.fr If I recall correctly there is a defaultStyleTable subduedStyleTable Stef On Feb 7, 2011, at 12:21 PM, Tudor Girba wrote: Hi, I am not sure what is the preferred way to set Shout programmatically. Can anyone point me to a script that already does that? I would be interested in proposing another color configuration and package it with the Glamorous Theme. Cheers, Doru -- www.tudorgirba.com No matter how many recipes we know, we still value a chef. -- www.tudorgirba.com Every now and then stop and ask yourself if the war you're fighting is the right one.
Re: [Pharo-project] A tinyBenchmark
On 10 Feb 2011, at 19:49, Marcus Denker wrote: On Feb 10, 2011, at 10:18 AM, Eliot Miranda wrote: In the Cog-Benchmarks (in Cog package) that I uploaded to squeaksource recently you'll find ShootoutTests which has 4 tests from the computer language shootouts that are pure Smalltalk. Camillo and Toon did a nice benchmarks framework for Pinnoccio... we should look at it. And we need something like this: http://speed.pypy.org/timeline/ This is impressive. Doru Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. -- www.tudorgirba.com To lead is not to demand things, it is to make them happen.
Re: [Pharo-project] SqueakSource down?
It all looks fine now. Doru On 11 Feb 2011, at 08:59, Fabrizio Perin wrote: No is the internet connection of university of bern that is down!!! Fabrizio 2011/2/11 Alexander Lazarević l...@blobworks.com http://www.downforeveryoneorjustme.com/www.squeaksource.com -- www.tudorgirba.com Speaking louder won't make the point worthier.
[Pharo-project] saving a monticello working copy
Hi, Does anyone know a simple way to save a Monticello working copy into the package-cache? Cheers, Doru -- www.tudorgirba.com Problem solving should be focused on describing the problem in a way that makes the solution obvious.
Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:
Hi, I also think we do not need caseOf: in the default distribution. It is probably useful for some cases (like dealing with integers from some external source as mentioned by Levente), but those cases are so rare that we should not affect everyone with this message. Cheers, Doru On 13 Feb 2011, at 08:57, Stéphane Ducasse wrote: Hi ricardo, igor and levente I really want to remove caseOf: since years. Why: - conceptually wrong (even if this may be nice to have for $A and numbers) - to me it looks like coming from another age - never needs to use it: of course other people may of course - Three less methods in Object - only available in Squeak/Pharo - but more more more important: makes the compiler, decompiler, inliner., more complex. I want opal to get out because we need a better infrastructure: simpler, better compiler. - Ideally I would prefer that we can extend the compiler with it and that people needed it just ship a plugin with their code. Marcus is opal dealing with caseOf:? I did not want to have a war. I thought that it was pretty obvious that we do not really need that. Stef Ok, guys... I'm sorry to interrupt this polite discussion, but this is taking nowhere. Having such strong arguments (for or against) is not helpful for anybody. We all know using #caseOf:otherwise: it's not exactly good style, but sometimes you need to compromise between design and efficiency, and having simple and efficient constructs such as #caseOf: is very good IMHO. You are free to avoid them if your projects don't need it, and if you happen to need extra performance you can always build your own JIT, right? :) But please don't ban people who are willing to sacrifice a little readability for performance reasons. Thanks. Best regards. Richo -- www.tudorgirba.com Value is always contextual.
Re: [Pharo-project] [Hudson] Cog Unix build
Great job! Doru On 13 Feb 2011, at 09:56, Sven Van Caekenberghe wrote: On 12 Feb 2011, at 23:19, Igor Stasenko wrote: Yes. i found the issue. Now it runs!!! :) And i were able to run all tests in pharo 1.3 core image on StackVM: 7864 run, 7787 passes, 51 expected failures, 8 failures, 17 errors, 1 unexpected passes no more crashes! :) That is really great and very impressive as well ! Sven -- www.tudorgirba.com The coherence of a trip is given by the clearness of the goal.
[Pharo-project] sprint in lille on march 12?
Hi, There was some mentioning of a Pharo Sprint after the Smalltalk School on March 12. Is there one, or do we do some programming during the school days? Cheers, Doru -- www.tudorgirba.com What is more important: To be happy, or to make happy?
Re: [Pharo-project] RPackage images
Thanks Cyrille. It is also useful to announce that Moose now relies on RPackage to import models out of Smalltalk code. Cheers, Doru On 15 Feb 2011, at 10:38, Cyrille Delaunay wrote: We have now an hudson job that build images with RPackage integrated and that run all the tests in the image: https://pharo-ic.lille.inria.fr/hudson/view/Pharo-TaskForces/job/Pharo%20RPackage%20All%20Tests/ Feel free to use it and report any problem. See also: http://code.google.com/p/pharo/issues/detail?id=3609q=RPackagecolspec=ID%20Type%20Status%20Summary%20Milestone%20Difficulty -- www.tudorgirba.com No matter how many recipes we know, we still value a chef.
Re: [Pharo-project] RPackage images
On 15 Feb 2011, at 12:25, Torsten Bergmann wrote: Is there any documentation available on RPackage already? Or a help book? There is some comments in the classes RPackage and RPackageOrganizer. OK, and now there is also a help book ;) One can try the package stuff and read the docu using: --- Gofer new squeaksource: 'PharoTaskForces'; package: 'ConfigurationOfRPackage'; load. ((Smalltalk at: #ConfigurationOfRPackage) project version: 'default') load. HelpBrowser open --- BTW: I still wonder why the classes are called RPackage and RPackageOrganizer instead of Package and PackageOrganizer. Because of name clashes. Cheers, Doru Keep on talking small T. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de -- www.tudorgirba.com Don't give to get. Just give.
Re: [Pharo-project] Working with weak announcements...
Hi Esteban, I finished the Glamour changes to only use on:send:to: between the Glamour model and the Glamour renderer. Cheers, Doru On 15 Feb 2011, at 17:37, Tudor Girba wrote: Hi Esteban, I started to refactor all usages of on:do: and when:do: into on:send:to: in the core of Glamour. I am almost finished. Now the only question is if we want to distinguish between WeakAnnouncer and Announcer. Is there a performance penalty or another kind of drawback in merging the two and use the WeakAnnouncer implementation only? The other thing is that we need to add on:send:to:with: and on:send:to:withAll: because we need to handle extra parameters (given that we cannot access local variables). Cheers, Doru On 15 Feb 2011, at 13:45, Esteban Lorenzano wrote: Well... not exactly, still something to do: the weak associations on weakannouncer are getting a lot of pairs #selector-nil and we need to think in a way to clean this. But this is doable :) In other order of things, I think we should explicitly forbid the use of #on:do: and #when:do: until the fix for blocks is ready. Cheers, Esteban El 14/02/2011, a las 6:55p.m., Tudor Girba escribió: Aha. Thanks a lot. Ok, let's do that. Is it true that the Lukas' Announcements already provide the support for on:send:to: ? Cheers, Doru On 14 Feb 2011, at 22:04, Esteban Lorenzano wrote: Hi, Well, this means, in the mean time, if we want to solve our issue 492 using weak announcements, we need to replace all #on:do: calls for #on:send:to: :( Cheers, Esteban Inicio del mensaje reenviado: De: Stéphane Ducasse stephane.duca...@inria.fr Fecha: 14 de febrero de 2011 17:57:07 GMT-03:00 Para: Pharo-project@lists.gforge.inria.fr Asunto: Re: [Pharo-project] Working with weak announcements... Responder a: Pharo-project@lists.gforge.inria.fr good question :) On FHi, I'm working with weak announcements, good we need that. Igor was telling me that the right anwser are ephemerons (but for that: gc change is required). Now it would be good to have first a solution at image level trying to make it work, and I have a problem in #on:do: protocol (or #when:do:) I try to explain: This method receives a block, not an object/selector, so I can't create a WeakMessageSend which is the appropriate message to handle in other cases. Well, the real question is... how can I produce a Weak BlockClosure reference who can die if receiver dies? I tried some hacks (really ugly hacks, btw), but fail completely. Any idea? best, Esteban -- www.tudorgirba.com Problem solving efficiency grows with the abstractness level of problem understanding. -- www.tudorgirba.com Reasonable is what we are accustomed with. -- www.tudorgirba.com Every now and then stop and ask yourself if the war you're fighting is the right one.
[Pharo-project] weak announcements
Hi everyone, So, the current situation is that we can make rather quickly on:send:to: work weakly. There is an almost working version in Lukas' repository, and Esteban and me will try to get it to work. Now, the question is where to publish this. I would suggest to create an official squeaksource.com/announcements repository. Is that Ok for you, or do you prefer to have it in squeaksource.com/PharoTaskForces? Cheers, Doru On 15 Feb 2011, at 18:21, Tudor Girba wrote: Hi Esteban, I finished the Glamour changes to only use on:send:to: between the Glamour model and the Glamour renderer. Cheers, Doru On 15 Feb 2011, at 17:37, Tudor Girba wrote: Hi Esteban, I started to refactor all usages of on:do: and when:do: into on:send:to: in the core of Glamour. I am almost finished. Now the only question is if we want to distinguish between WeakAnnouncer and Announcer. Is there a performance penalty or another kind of drawback in merging the two and use the WeakAnnouncer implementation only? The other thing is that we need to add on:send:to:with: and on:send:to:withAll: because we need to handle extra parameters (given that we cannot access local variables). Cheers, Doru On 15 Feb 2011, at 13:45, Esteban Lorenzano wrote: Well... not exactly, still something to do: the weak associations on weakannouncer are getting a lot of pairs #selector-nil and we need to think in a way to clean this. But this is doable :) In other order of things, I think we should explicitly forbid the use of #on:do: and #when:do: until the fix for blocks is ready. Cheers, Esteban El 14/02/2011, a las 6:55p.m., Tudor Girba escribió: Aha. Thanks a lot. Ok, let's do that. Is it true that the Lukas' Announcements already provide the support for on:send:to: ? Cheers, Doru On 14 Feb 2011, at 22:04, Esteban Lorenzano wrote: Hi, Well, this means, in the mean time, if we want to solve our issue 492 using weak announcements, we need to replace all #on:do: calls for #on:send:to: :( Cheers, Esteban Inicio del mensaje reenviado: De: Stéphane Ducasse stephane.duca...@inria.fr Fecha: 14 de febrero de 2011 17:57:07 GMT-03:00 Para: Pharo-project@lists.gforge.inria.fr Asunto: Re: [Pharo-project] Working with weak announcements... Responder a: Pharo-project@lists.gforge.inria.fr good question :) On FHi, I'm working with weak announcements, good we need that. Igor was telling me that the right anwser are ephemerons (but for that: gc change is required). Now it would be good to have first a solution at image level trying to make it work, and I have a problem in #on:do: protocol (or #when:do:) I try to explain: This method receives a block, not an object/selector, so I can't create a WeakMessageSend which is the appropriate message to handle in other cases. Well, the real question is... how can I produce a Weak BlockClosure reference who can die if receiver dies? I tried some hacks (really ugly hacks, btw), but fail completely. Any idea? best, Esteban -- www.tudorgirba.com Problem solving efficiency grows with the abstractness level of problem understanding. -- www.tudorgirba.com Reasonable is what we are accustomed with. -- www.tudorgirba.com Every now and then stop and ask yourself if the war you're fighting is the right one. -- www.tudorgirba.com The coherence of a trip is given by the clearness of the goal.
Re: [Pharo-project] weak announcements
Hi, Yes, it is meant to be integrated in Pharo 1.3. Ok, but then PharoTaskForces should not delete the packages after they are integrated. The reason is that I want to use these announcements before you release 1.3, and thus it will appear in ConfigurationOfGlamour. Is that Ok? Cheers, Doru On 15 Feb 2011, at 18:53, Stéphane Ducasse wrote: if this is to be integrated in 1.3 (which I hope :)) then I would prefer PharoTaskForces Stef Hi everyone, So, the current situation is that we can make rather quickly on:send:to: work weakly. There is an almost working version in Lukas' repository, and Esteban and me will try to get it to work. Now, the question is where to publish this. I would suggest to create an official squeaksource.com/announcements repository. Is that Ok for you, or do you prefer to have it in squeaksource.com/PharoTaskForces? Cheers, Doru On 15 Feb 2011, at 18:21, Tudor Girba wrote: Hi Esteban, I finished the Glamour changes to only use on:send:to: between the Glamour model and the Glamour renderer. Cheers, Doru On 15 Feb 2011, at 17:37, Tudor Girba wrote: Hi Esteban, I started to refactor all usages of on:do: and when:do: into on:send:to: in the core of Glamour. I am almost finished. Now the only question is if we want to distinguish between WeakAnnouncer and Announcer. Is there a performance penalty or another kind of drawback in merging the two and use the WeakAnnouncer implementation only? The other thing is that we need to add on:send:to:with: and on:send:to:withAll: because we need to handle extra parameters (given that we cannot access local variables). Cheers, Doru On 15 Feb 2011, at 13:45, Esteban Lorenzano wrote: Well... not exactly, still something to do: the weak associations on weakannouncer are getting a lot of pairs #selector-nil and we need to think in a way to clean this. But this is doable :) In other order of things, I think we should explicitly forbid the use of #on:do: and #when:do: until the fix for blocks is ready. Cheers, Esteban El 14/02/2011, a las 6:55p.m., Tudor Girba escribió: Aha. Thanks a lot. Ok, let's do that. Is it true that the Lukas' Announcements already provide the support for on:send:to: ? Cheers, Doru On 14 Feb 2011, at 22:04, Esteban Lorenzano wrote: Hi, Well, this means, in the mean time, if we want to solve our issue 492 using weak announcements, we need to replace all #on:do: calls for #on:send:to: :( Cheers, Esteban Inicio del mensaje reenviado: De: Stéphane Ducasse stephane.duca...@inria.fr Fecha: 14 de febrero de 2011 17:57:07 GMT-03:00 Para: Pharo-project@lists.gforge.inria.fr Asunto: Re: [Pharo-project] Working with weak announcements... Responder a: Pharo-project@lists.gforge.inria.fr good question :) On FHi, I'm working with weak announcements, good we need that. Igor was telling me that the right anwser are ephemerons (but for that: gc change is required). Now it would be good to have first a solution at image level trying to make it work, and I have a problem in #on:do: protocol (or #when:do:) I try to explain: This method receives a block, not an object/selector, so I can't create a WeakMessageSend which is the appropriate message to handle in other cases. Well, the real question is... how can I produce a Weak BlockClosure reference who can die if receiver dies? I tried some hacks (really ugly hacks, btw), but fail completely. Any idea? best, Esteban -- www.tudorgirba.com Problem solving efficiency grows with the abstractness level of problem understanding. -- www.tudorgirba.com Reasonable is what we are accustomed with. -- www.tudorgirba.com Every now and then stop and ask yourself if the war you're fighting is the right one. -- www.tudorgirba.com The coherence of a trip is given by the clearness of the goal. -- www.tudorgirba.com Some battles are better lost than fought.
Re: [Pharo-project] weak announcements
I committed the packages in PharoTaskForces. Cheers, Doru On 15 Feb 2011, at 19:20, Stéphane Ducasse wrote: Hi, Yes, it is meant to be integrated in Pharo 1.3. Ok, but then PharoTaskForces should not delete the packages after they are integrated. they will just be moved to pharo for history management. The reason is that I want to use these announcements before you release 1.3, and thus it will appear in ConfigurationOfGlamour. Is that Ok? Sure! Cheers, Doru On 15 Feb 2011, at 18:53, Stéphane Ducasse wrote: if this is to be integrated in 1.3 (which I hope :)) then I would prefer PharoTaskForces Stef Hi everyone, So, the current situation is that we can make rather quickly on:send:to: work weakly. There is an almost working version in Lukas' repository, and Esteban and me will try to get it to work. Now, the question is where to publish this. I would suggest to create an official squeaksource.com/announcements repository. Is that Ok for you, or do you prefer to have it in squeaksource.com/PharoTaskForces? Cheers, Doru On 15 Feb 2011, at 18:21, Tudor Girba wrote: Hi Esteban, I finished the Glamour changes to only use on:send:to: between the Glamour model and the Glamour renderer. Cheers, Doru On 15 Feb 2011, at 17:37, Tudor Girba wrote: Hi Esteban, I started to refactor all usages of on:do: and when:do: into on:send:to: in the core of Glamour. I am almost finished. Now the only question is if we want to distinguish between WeakAnnouncer and Announcer. Is there a performance penalty or another kind of drawback in merging the two and use the WeakAnnouncer implementation only? The other thing is that we need to add on:send:to:with: and on:send:to:withAll: because we need to handle extra parameters (given that we cannot access local variables). Cheers, Doru On 15 Feb 2011, at 13:45, Esteban Lorenzano wrote: Well... not exactly, still something to do: the weak associations on weakannouncer are getting a lot of pairs #selector-nil and we need to think in a way to clean this. But this is doable :) In other order of things, I think we should explicitly forbid the use of #on:do: and #when:do: until the fix for blocks is ready. Cheers, Esteban El 14/02/2011, a las 6:55p.m., Tudor Girba escribió: Aha. Thanks a lot. Ok, let's do that. Is it true that the Lukas' Announcements already provide the support for on:send:to: ? Cheers, Doru On 14 Feb 2011, at 22:04, Esteban Lorenzano wrote: Hi, Well, this means, in the mean time, if we want to solve our issue 492 using weak announcements, we need to replace all #on:do: calls for #on:send:to: :( Cheers, Esteban Inicio del mensaje reenviado: De: Stéphane Ducasse stephane.duca...@inria.fr Fecha: 14 de febrero de 2011 17:57:07 GMT-03:00 Para: Pharo-project@lists.gforge.inria.fr Asunto: Re: [Pharo-project] Working with weak announcements... Responder a: Pharo-project@lists.gforge.inria.fr good question :) On FHi, I'm working with weak announcements, good we need that. Igor was telling me that the right anwser are ephemerons (but for that: gc change is required). Now it would be good to have first a solution at image level trying to make it work, and I have a problem in #on:do: protocol (or #when:do:) I try to explain: This method receives a block, not an object/selector, so I can't create a WeakMessageSend which is the appropriate message to handle in other cases. Well, the real question is... how can I produce a Weak BlockClosure reference who can die if receiver dies? I tried some hacks (really ugly hacks, btw), but fail completely. Any idea? best, Esteban -- www.tudorgirba.com Problem solving efficiency grows with the abstractness level of problem understanding. -- www.tudorgirba.com Reasonable is what we are accustomed with. -- www.tudorgirba.com Every now and then stop and ask yourself if the war you're fighting is the right one. -- www.tudorgirba.com The coherence of a trip is given by the clearness of the goal. -- www.tudorgirba.com Some battles are better lost than fought. -- www.tudorgirba.com What we can governs what we wish.
Re: [Pharo-project] [Moose-dev] Problem loading JNIPort
Hi Cyrille, Did you manage to get JNIPort working on Pharo 1.2? Cheers, Doru On 14 Feb 2011, at 12:16, Tudor Girba wrote: Hi Matthias, Thanks for reporting. I forwarded the message to the Pharo mailing list as well. Can anyone help? Cheers, Doru On 14 Feb 2011, at 12:10, Matthias Junker wrote: Hi, i was trying to load JNIPort as described on squeaksource on my Macbook (OS X 10.6.6). I downloaded the latest Pharo 1.2 from Hudson (https://pharo-ic.lille.inria.fr/hudson/view/Pharo/job/Pharo%201.2/) and opened it using SqueakVM 5.8b12. I was able to load Alien using the following command: Gofer it squeaksource:'MetacelloRepository' ; package: 'ConfigurationOfAlien'; load. ((Smalltalk globals classNamed: 'ConfigurationOfAlien') project version: 'Pharo 1.2') load: 'Core'; load: 'LibC Then i loaded the JNIPort Configuration: Gofer it squeaksource: 'JNIPort'; package: 'ConfigurationOfJNIPort'; load. But when i load the actual project with this: ConfigurationOfJNIPort project latestVersion load I get the following error in the class StandardLibInterface(AlienLibrary)load libraryName: '/System/Library/Frameworks/System.framework/System' errorCode: #'not found' When i check on the file system i find a symbolic link which points to /usr/lib/libSystem.B.dylib (which also exists there). Any hints to what i'm doing wrong? Cheers, Matt ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com In a world where everything is moving ever faster, one might have better chances to win by moving slower. -- www.tudorgirba.com When people care, great things can happen.
Re: [Pharo-project] [Pharo-users] Call for Pharo Support **important**
The reason I am asking is that in the text you say if your company/research group would be interested, which tends to not invite individuals. Ok, so individuals should sign it, too? Cheers, Doru On 16 Feb 2011, at 23:01, Stéphane Ducasse wrote: both this is a user and industrial consortium. may be I'm a dreamer but I would like something open to the community in general. Stef On Feb 16, 2011, at 10:11 PM, Tudor Girba wrote: Just a question: are you interested only in companies/groups or also individuals? Cheers, Doru On 16 Feb 2011, at 16:38, Stéphane Ducasse wrote: Dear Pharoers We are pursuing an effort to bring Pharo to the next level: we will set up a consortium of pharo users and industrial partners. Our goal is to build a legal infrastructure that will be able to sustain the development of Pharo and improve its future. As an example, we would like to be able to collect funds (ways as to be determined - we foresee a membership model or moral license) to pay engineering tasks to be performed such as improving the virtual machine, network libraries, better JIT support. To make it short we would like to give a chance to our community to grow and structure itself so that Pharo can get stronger and that risk (truck factor) gets minimized. We are contacting you to know if your company/research group would be interested to support such effort. Showing such interest is strategically important for us and INRIA which could also support such effort. Attached is the letter of support that we will collect once signed and scanned ( stephane.duca...@inria.fr / faxed at: 00 33 (0)3 59 57 78 50) Thanks for your support The Pharo Board M. Denker, S. Ducasse, and A. Lienhard Pharo-LetterOfSupport-EN-V2.doc -- www.tudorgirba.com Presenting is storytelling. -- www.tudorgirba.com Value is always contextual.
Re: [Pharo-project] saving a monticello working copy
Hi Sven, The scenario is like this: - I have an image in a new folder without any package-cache subfolder - I want to save programmatically a package from the image working copy to the package-cache folder (without creating a new version if possible) I need this for a test fixture that needs to ensure that a certain mcz is in the package-cache, but without depending on copying files around. Cheers, Doru On 14 Feb 2011, at 12:23, Sven Van Caekenberghe wrote: Doru, On 14 Feb 2011, at 12:18, Tudor Girba wrote: Basically, I need that given a working copy in the image, to copy it in the local package-cache. I am not sure I understand. For each MC package, your image's local package-cache is always one of the possible repositories, so why can't you just save it right there ? And later on copy it to some other repository. I am sure you know that, so your problem must be something else, no ? Sven -- www.tudorgirba.com Not knowing how to do something is not an argument for how it cannot be done.
Re: [Pharo-project] Hudson builds are cool
Hi Marcus, Is it possible to make the latest vm executables available over http? Like that we can use them in the Moose builds as well. Cheers, Doru On 19 Feb 2011, at 17:59, Marcus Denker wrote: On Feb 19, 2011, at 1:03 AM, Miguel Cobá wrote: I haven't had time to use Pharo 1.2 from Hudson until now. All I have to say is: amazing work (or job :) We need to update the vms used for the build... will do that at some point next week when back home. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. -- www.tudorgirba.com Every successful trip needs a suitable vehicle.
Re: [Pharo-project] Hudson builds are cool
Sounds cool! I will look into it. Cheers, Doru On 19 Feb 2011, at 19:24, Igor Stasenko wrote: On 19 February 2011 18:19, Tudor Girba tudor.gi...@gmail.com wrote: Hi Marcus, Is it possible to make the latest vm executables available over http? Like that we can use them in the Moose builds as well. They are available. https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/Cog%20Unix%201.3/lastSuccessfulBuild/artifact/sig-cog/build/Cog.zip https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/Stack%20VM%20Unix/lastSuccessfulBuild/artifact/StackVM.zip except that they are currently disabled, because we're lacking free space on server :) The configurations is not perfect. And they are not packaged similarily to original build. It is just a single directory with all binaries (VM and libs). Cheers, Doru On 19 Feb 2011, at 17:59, Marcus Denker wrote: On Feb 19, 2011, at 1:03 AM, Miguel Cobá wrote: I haven't had time to use Pharo 1.2 from Hudson until now. All I have to say is: amazing work (or job :) We need to update the vms used for the build... will do that at some point next week when back home. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. -- www.tudorgirba.com Every successful trip needs a suitable vehicle. -- Best regards, Igor Stasenko AKA sig. -- www.tudorgirba.com What we can governs what we wish.
[Pharo-project] [ANN] Moose 4.3
We are happy to announce the Moose Suite version 4.3: *http://moosetechnology.org/download* What is new: - New look and feel - New and flexible API to browse FAMIX models - Extensible Moose Finder - Enhanced Glamour engine to deal with complex actions - Enhanced FAMIX support for Java systems - Enhanced Glamour rendering for Morphic - Enhanced meta browser - Enhanced documentation of Mondrian - Enhanced XMLSupport - Enhanced Smalltalk importer A list of issues addressed in this release can be found at: *http://code.google.com/p/moose-technology/issues/list?can=1q=status=Fixed%20milestone=4.3* Have fun, The Moose Team
Re: [Pharo-project] Squeaksource down
Thanks for taking care of this, Fabrizio. Cheers, Doru On 21 Feb 2011, at 15:58, Fabrizio Perin wrote: up again 2011/2/21 Fabrizio Perin fabrizio.pe...@gmail.com I know, it goes down 5 minutes ago. If it is not urgent try again in 30 mins. 2011/2/21 Hilaire Fernandes hilaire.fernan...@gmail.com Seems it is down Hilaire -- Education 0.2 -- http://blog.ofset.org/hilaire -- www.tudorgirba.com Beauty is where we see it.
Re: [Pharo-project] Community in the IDE
Cool initiative. I gave it a try, but could not get it to work. What I did was to start it on port 8000, and then try to connect to localhost / 8000 (in the dialog). What am I doing wrong? Cheers, Doru On 22 Feb 2011, at 17:35, Benjamin wrote: Hello guys, I've done a very simple Pharo Messenger that you can test here: Gofer new squeaksource: 'PharoInstantMessenge'; package: 'PIM'; load For launching the server: ChatServerLauncher launch: aPortNumber. For launching the client: WindowsManager default openInWorld. I will see if I can found a server to put the image :) Thanks in advance for your feedbacks, Ben -- www.tudorgirba.com What is more important: To be happy, or to make happy?
Re: [Pharo-project] Fwd: [ANN] pharo focused sprint - bern, feb 26
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 tudor.gi...@gmail.com Date: 1 February 2011 16:38:30 CET To: Pharo-project@lists.gforge.inria.fr Development pharo-project@lists.gforge.inria.fr Cc: Adrian Lienhard alienh...@netstyle.ch 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.
Re: [Pharo-project] Fwd: [ANN] pharo focused sprint - bern, feb 26
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 tudor.gi...@gmail.com 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 tudor.gi...@gmail.com Date: 1 February 2011 16:38:30 CET To: Pharo-project@lists.gforge.inria.fr Development pharo-project@lists.gforge.inria.fr Cc: Adrian Lienhard alienh...@netstyle.ch 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.
Re: [Pharo-project] we cannot add attachment anymore on the bug tracker
Isn't it because you went passed the quota? The bad thing about attachments in Google Code is that you have only 50MB for it. You can find the current status in Administer/Advanced. Cheers, Doru On 25 Feb 2011, at 18:58, Igor Stasenko wrote: On 25 February 2011 18:54, Stéphane Ducasse stephane.duca...@inria.fr wrote: Hi guys does anybody know how we can fix that? whaaat? that's really bad :( Stef -- Best regards, Igor Stasenko AKA sig. -- www.tudorgirba.com Yesterday is a fact. Tomorrow is a possibility. Today is a challenge.
Re: [Pharo-project] Fwd: [ANN] pharo focused sprint - bern, feb 26
Phenomenal :) Doru On 24 Feb 2011, at 13:03, Jorge Ressia wrote: I will be there too. Cheers, On Wed, Feb 23, 2011 at 10:44 PM, Tudor Girba tudor.gi...@gmail.com 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 tudor.gi...@gmail.com 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 tudor.gi...@gmail.com Date: 1 February 2011 16:38:30 CET To: Pharo-project@lists.gforge.inria.fr Development pharo-project@lists.gforge.inria.fr Cc: Adrian Lienhard alienh...@netstyle.ch 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 -- www.tudorgirba.com Yesterday is a fact. Tomorrow is a possibility. Today is a challenge.
Re: [Pharo-project] Metacello Configuration Pharo1.2 solo sprint Portland, Oregon ... Saturday and Sunday
Thanks indeed for all this nice work and commitment. Cheers, Doru On 26 Feb 2011, at 05:13, Miguel Cobá wrote: Thanks Dale El vie, 25-02-2011 a las 17:27 -0800, Dale Henrichs escribió: Okay, okay I've been trying to keep a half dozen balls in the air for the last few weeks and what that means is that I don't give enough attention to any of them ... Pharo1.2 is close and Metacello is one of the bad boys with the failing tests so, I am going to do a solo sprint this weekend: 1. a quick release of Metacello with expectedFailures for the tests that are failing in Pharo1.2. I have already fixed the tests (only test changes are needed), but I now need to port the Gofer changes to Squeak and GemStone which is a bigger job. A quick surgical set of expectedFailures is the best thing to do here. 2. in build #57 of Pharo1.2 I noticed some odd things that I want to track down... 3. I expect that some of the #57 issues can be revealed with the validator, so I am thinking that I will run the validator over all of the configurations that are used in Pharo1.2 and go about identify and/or fixing the meaningful issues that I find. My main goal will be to repair things that are broken, so I will be reluctant to make semantic changes without checking with the maintainers, but if the problem is really gruesome I will fix it and apologize later:) 4. I'm not going to spend a lot of time reading/writing email ... this will be a sprint not a coffee klatch. With that said, if you have a Metacello config issue that is related to Pharo1.2 drop me an email with your question/thought but don't be offended if I don't respond at all or just GRUNT in reply ... I may even take action without letting you know... 5. While working on the above task, I will work on the MetacelloBrowser adding menu items for the operations that I performso it will then be easier for other folks to perform the same types of jobs in the future. I may do something funky like hide the menu items behind a boolean so as not to pollute the menu items with a whole bunch of advanced type operations (that will be named poorly:)... I realize that I may be closing the barn door after the horse is gone - build 57 is yellow afterall - but cleaning up validation issues is long overdue. I don't plan on fixing Metacello bugs unless I find something that just begs to be fixed ... the sprint is mainly about running the validator and cleaning up the real nasty bits and track down the Metacello anomalies in #57... Dale -- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx -- www.tudorgirba.com Speaking louder won't make the point worthier.
Re: [Pharo-project] Fwd: [ANN] pharo focused sprint - bern, feb 26
We are starting the sprint: - Twitter tag: #pharosprint - If someone wants to join remotely, let us know how to reach you. Gary, Alain? :) Cheers, Doru On 25 Feb 2011, at 20:39, Tudor Girba wrote: Phenomenal :) Doru On 24 Feb 2011, at 13:03, Jorge Ressia wrote: I will be there too. Cheers, On Wed, Feb 23, 2011 at 10:44 PM, Tudor Girba tudor.gi...@gmail.com 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 tudor.gi...@gmail.com 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 tudor.gi...@gmail.com Date: 1 February 2011 16:38:30 CET To: Pharo-project@lists.gforge.inria.fr Development pharo-project@lists.gforge.inria.fr Cc: Adrian Lienhard alienh...@netstyle.ch 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 -- www.tudorgirba.com Yesterday is a fact. Tomorrow is a possibility. Today is a challenge. -- www.tudorgirba.com Be rather willing to give than demanding to get.
Re: [Pharo-project] introducing RPackage :)
Hi, We use RPackage in Moose, and it works fine. We only encountered a small problem raised when renaming a class, but Cyrille fixed that, too. I am quite confident in it. The way to load it is like this (different repo): Gofer new squeaksource: 'PharoTaskForces'; package: 'ConfigurationOfRPackage'; load. (Smalltalk at: #ConfigurationOfRPackage) perform: #loadDefault. The translation of SystemChangeNotifier into Announcements happens in SystemAnnouncements package. Just a note, until we can remove the SystemChangeNotifier, we have to first get Monticello work with RPackage and SystemAnnouncements. Afterwards, we should hook Announcements directly in the system, and yet afterwards remove the categories and get the tools work with RPackage. Cheers, Doru On 26 Feb 2011, at 18:59, Stéphane Ducasse wrote: Hi guys I would like to give a try to introduce RPackage = a complete rewrite of PackageInfo. Moose people use it and I will sync with them to know. It would be great if some of you could load and play with the system Gofer new squeaksource: 'PharoInbox'; package: 'ConfigurationOfRPackage'; load. (Smalltalk at: #ConfigurationOfRPackage) perform: #loadDefault. Note that RPackage is based on announcement. So there is just one place that register to systemNotifier. So one of the following goal is to remove SystemChangeNotifier and replace it with announcement. Stef -- www.tudorgirba.com Every thing should have the right to be different.
Re: [Pharo-project] Fwd: [ANN] pharo focused sprint - bern, feb 26
Hi, The sprint was quite exciting. Here is the twitter report: http://twitter.com/#!/search/pharosprint Here is a longer report: - Camillo looked into Keymapping. He spent several hours going through the code with the debugger. In the process he extracted more actions into keybindings (in the Keymapping-Settings). It's a commendable effort because it is quite a challenge to debug the system when playing with the keybindings :). The conclusion seems to be that Keymapping provides good functionality already, but that it needs some refactoring. In particular: --- There should be less decisions in the TextMorph. These should be delegated to the Dispatcher --- Some classes and methods would do with better names. For example, keyMapper / hasKeymap / Dispatcher. They should be all Keymapper --- There are a couple of symbols around (e.g., #complete) that are not quite clear and that should be modeled explicitly. --- Camillo, did I miss anything? - Lukas went over the WeakAnnouncements implementation to get the WeakMessageSend working. The code is in PharoTaskForces - Lukas worked on getting OB work with the changes in TextMorph from Pharo 1.2. - Adrian, Jorge and Toon worked on implementing a Debugger on top of Glamour. They got a first version working that is able to do basic actions: step, restart, step into. The challenge was to get to understand the model, and to figure out that primitive: 19 is used for marking that a method should not be debugged. In any case, working with Glamour seemed to work quite smoothly. The code is available in the Glamorous Toolkit. Adrian, did I get it right? :) - Mircea built a new widget for searching multiple categories of items in the same time, similar to spotlight where you enter one string and you get multiple hits from multiple categories. The implementation was spawned from the OBCompletionDialog / OBCompletionRequest and currently it simply provides multiple lists one below the other. The idea is to use this kind of widget to search simultaneously for classes / methods / packages. The code is available in Glamour (Glamour-Morphic-Renderer). The widget can definitely be improved visually, but Mircea already did a nice job. - I showed the current prototypes available in the Glamorous Toolkit (built with Glamour). It looks like we got a consensus that we should focus on rethinking the IDEs, and that Glamour can be a promising infrastructure. For this to work, we distinguished between the work needed at the widget level (like the work of Mircea and Camillo), and the work needed at the level of playing with new metaphors for browsing. The Glamorous Toolkit already provides a number of examples for: ObjectFinder, Chaser, Playground (ex-Workspace), MessageTallyBrowser, ProfStef, and some Coders. If you want to play with the early versions of these tools, you can get them here (just keep in mind that they are intended as exercises at the moment): Gofer new squeaksource: 'glamoroust'; package: 'ConfigurationOfGlamoroust'; load. (Smalltalk at: #ConfigurationOfGlamoroust) perform: #loadDefault. Cheers, Doru On 26 Feb 2011, at 19:06, Stéphane Ducasse wrote: so doru I just arrived after a trip from the nearly westernest town in france to nearly the northest one :) What are the results of the sprint. On Feb 26, 2011, at 9:42 AM, Tudor Girba wrote: We are starting the sprint: - Twitter tag: #pharosprint - If someone wants to join remotely, let us know how to reach you. Gary, Alain? :) Cheers, Doru On 25 Feb 2011, at 20:39, Tudor Girba wrote: Phenomenal :) Doru On 24 Feb 2011, at 13:03, Jorge Ressia wrote: I will be there too. Cheers, On Wed, Feb 23, 2011 at 10:44 PM, Tudor Girba tudor.gi...@gmail.com 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 tudor.gi...@gmail.com 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 tudor.gi...@gmail.com Date: 1 February 2011 16:38:30 CET To: Pharo-project@lists.gforge.inria.fr Development pharo-project@lists.gforge.inria.fr Cc: Adrian Lienhard alienh...@netstyle.ch Subject: [ANN] pharo focused sprint - bern, feb 26 Hi, We would like to organize a Pharo Sprint on Saturday, February 26 at SCG, University
Re: [Pharo-project] we cannot add attachment anymore on the bug tracker
Yes. Lukas pointed us to the docs. You can find the answer here: http://code.google.com/p/support/wiki/FAQ#What_other_limits_exist? Cheers, Doru On 26 Feb 2011, at 22:05, Stéphane Ducasse wrote: tx lukas Do you know if there is a normal process to request such increase? Stef On Feb 25, 2011, at 11:53 PM, Lukas Renggli wrote: Thanks for letting me know. Getting the quota increased is pretty easy (kudos Nathaniel), if you ask the right people ;-) Lukas On 25 February 2011 22:29, Marcus Denker marcus.den...@inria.fr wrote: On Feb 25, 2011, at 8:33 PM, Tudor Girba wrote: Isn't it because you went passed the quota? The bad thing about attachments in Google Code is that you have only 50MB for it. You can find the current status in Administer/Advanced. Maybe this is the hint to move to something else... what I really want (need) is a bugtracker that allows better sorting of bug reports. Tags are great. But tags do not replace sub-projects. I want a bug tracker just for Cog. And one just for the nuts, or one for morphic... This way we could actually get structure in the 560 reports... Redmine (http://www.redmine.org/) supports sub-projects. Or maybe https://www.chiliproject.org/ (a fork of redmine). Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. -- Lukas Renggli www.lukas-renggli.ch -- www.tudorgirba.com Sometimes the best solution is not the best solution.
Re: [Pharo-project] About 1.2
Hi Stef, I think this is the right approach. I would suggest in the future to set a hard deadline a month before, and only include what works at that time. Like this people have time to react, and if they do not, you can safely remove things without anyone telling you that you did not warn them :) Cheers, Doru On 25 Feb 2011, at 21:50, Stéphane Ducasse wrote: Hi guys 1.2 should go out. Marcus and me should spend their time on 1.3, OPAL and the rest. Now for PharoDev we want to remove packages that are not about tools. If you want XML, openDBX... help us using Metacello to build distributions = something that will work in 1.2 when we will be in Pharo 10. Right now this is not normal that a problem in XML in 1.2 impacts the builds in 1.1. Proposing bloated images DOES NOT HELP US. Why? Because the goal is to have an INFRASTRUCTURE to take a small image with a metacello description repository and load whatever we want. In the future we want to use metacello to manage core and not to have a distinction between core and dev. We should be able to load all the time RBEngine and use it all the time to fix the system. Right now we are LOSING TIME on fixing 1.2 configs while we should invest in the infrastructure that will enable to be agile and load whatever configuration we/you will develop. So can we be focus on the infrastructure? The concept and tools that we will make us be really powerful in the future? So if the community does not hear our call, we the board will take actions. We do not want to do that but if this is necessary we will do it because we want 1.2 to get out. Stef -- www.tudorgirba.com What is more important: To be happy, or to make happy?
Re: [Pharo-project] Fwd: [ANN] pharo focused sprint - bern, feb 26
Hi, On 27 Feb 2011, at 08:58, Stéphane Ducasse wrote: ... - Lukas went over the WeakAnnouncements implementation to get the WeakMessageSend working. The code is in PharoTaskForces should we take action on this one? I mean integrating it. It can be integrated, because the base code works in the same way as before. Currently, the solution is implemented through a WeakAnnouncer which subclasses Announcer. I wanted the weak thing to be merged, because the clients of announcements should benefit from the Weak implementation, but Lukas says that he does not trust the Weak support in Pharo and that if you have many WeakAnnouncers it somehow does not scale. The problem with the current approach is that models have to take an explicit stand of whether they want weak or non weak when instantiating the announcer. Unfortunately, I do have enough technical knowledge for this. It would be cool if someone with better knowledge in this area would take a look. - Lukas worked on getting OB work with the changes in TextMorph from Pharo 1.2. - Adrian, Jorge and Toon worked on implementing a Debugger on top of Glamour. They got a first version working that is able to do basic actions: step, restart, step into. The challenge was to get to understand the model, and to figure out that primitive: 19 is used for marking that a method should not be debugged. In any case, working with Glamour seemed to work quite smoothly. The code is available in the Glamorous Toolkit. Adrian, did I get it right? :) - Mircea built a new widget for searching multiple categories of items in the same time, similar to spotlight where you enter one string and you get multiple hits from multiple categories. The implementation was spawned from the OBCompletionDialog / OBCompletionRequest and currently it simply provides multiple lists one below the other. The idea is to use this kind of widget to search simultaneously for classes / methods / packages. The code is available in Glamour (Glamour-Morphic-Renderer). The widget can definitely be improved visually, but Mircea already did a nice job. is the widget only for glamour because I think that a widget with search list integrated should be used everywhere? We were discussing with alain to have a look at the one in OB and push it/rewrite it as a core widget Neither the OB nor the Glamour widgets depend on Glamour, so they can be used independently. You just need to take the Request and the Dialog together. Cheers, Doru - I showed the current prototypes available in the Glamorous Toolkit (built with Glamour). It looks like we got a consensus that we should focus on rethinking the IDEs, and that Glamour can be a promising infrastructure. For this to work, we distinguished between the work needed at the widget level (like the work of Mircea and Camillo), and the work needed at the level of playing with new metaphors for browsing. The Glamorous Toolkit already provides a number of examples for: ObjectFinder, Chaser, Playground (ex-Workspace), MessageTallyBrowser, ProfStef, and some Coders. If you want to play with the early versions of these tools, you can get them here (just keep in mind that they are intended as exercises at the moment): Gofer new squeaksource: 'glamoroust'; package: 'ConfigurationOfGlamoroust'; load. (Smalltalk at: #ConfigurationOfGlamoroust) perform: #loadDefault. Cheers, Doru On 26 Feb 2011, at 19:06, Stéphane Ducasse wrote: so doru I just arrived after a trip from the nearly westernest town in france to nearly the northest one :) What are the results of the sprint. On Feb 26, 2011, at 9:42 AM, Tudor Girba wrote: We are starting the sprint: - Twitter tag: #pharosprint - If someone wants to join remotely, let us know how to reach you. Gary, Alain? :) Cheers, Doru On 25 Feb 2011, at 20:39, Tudor Girba wrote: Phenomenal :) Doru On 24 Feb 2011, at 13:03, Jorge Ressia wrote: I will be there too. Cheers, On Wed, Feb 23, 2011 at 10:44 PM, Tudor Girba tudor.gi...@gmail.com 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 tudor.gi...@gmail.com 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 tudor.gi
Re: [Pharo-project] [ANN] More on Keymappings
I also I cannot load Keymapping 1.5 in Pharo 1.2. I get DNU for Character+. This is due to an initialization in KMKeyEvent (see the attached debug log). I did the followings: Gofer it squeaksource: 'Keymapping'; package: 'ConfigurationOfKeymapping'; load. (ConfigurationOfKeymapping project version: #stable) load Am I missing something, or is this version not supposed to work in Pharo 1.2? Cheers, Doru PharoDebug.log Description: Binary data On 26 Feb 2011, at 21:08, Francisco Ortiz Peñaloza wrote: You're telling me that if i do a clean installation of 1.5 it would work? Thanks in advance, Francisco On Sat, Feb 26, 2011 at 3:50 PM, Guillermo Polito guillermopol...@gmail.com wrote: Mmm, If you had 1.4 and updated to 1.5, you will have some problems because I did some refactorings on that... :/. On Sat, Feb 26, 2011 at 10:12 AM, Francisco Ortiz Peñaloza patchi...@gmail.com wrote: Guille i was using 1.4 and worked excellent, just tried 1.5 and on every stroke i made i've got a DNU on #realtarget Installed on last PharoCore 1.2, should i try it on 1.3? Great work, Fran On Sat, Feb 26, 2011 at 5:29 AM, laurent laffont laurent.laff...@gmail.com wrote: On Sat, Feb 26, 2011 at 5:42 AM, Guillermo Polito guillermopol...@gmail.com wrote: What do we have now? - Can provide settings for a set of morphs - Can provide settings for a TextEditors (Smalltalk editor and related) - Settings integration I added some methods to the Settings Tree Builder in order to avoid references from the users code. - I ran Slint over it and cleaned it a lot more :). ( And learnt that Slint is there :P ) More info in here: http://guilleel3.blogspot.com/ A new blog, cool ! Can I have Emacs-like keybinding in code editor, to switch browser, ... ? Laurent. Guille -- www.tudorgirba.com Every thing has its own flow.
Re: [Pharo-project] Fwd: [ANN] pharo focused sprint - bern, feb 26
Hi, On 27 Feb 2011, at 12:04, Stéphane Ducasse wrote: - Lukas went over the WeakAnnouncements implementation to get the WeakMessageSend working. The code is in PharoTaskForces should we take action on this one? I mean integrating it. It can be integrated, because the base code works in the same way as before. Currently, the solution is implemented through a WeakAnnouncer which subclasses Announcer. I wanted the weak thing to be merged, because the clients of announcements should benefit from the Weak implementation, but Lukas says that he does not trust the Weak support in Pharo and that if you have many WeakAnnouncers it somehow does not scale. ok so ...? So, we need to investigate more :). It would be cool if someone with more knowledge would take a look, too. Igor, would you have a bit of time to look into it? I will probably also give it a look to see how it works in the context of Glamour. I hope that Esteban will join me again. Esteban, what do you say :)? The problem with the current approach is that models have to take an explicit stand of whether they want weak or non weak when instantiating the announcer. Unfortunately, I do have enough technical knowledge for this. It would be cool if someone with better knowledge in this area would take a look. - Lukas worked on getting OB work with the changes in TextMorph from Pharo 1.2. - Adrian, Jorge and Toon worked on implementing a Debugger on top of Glamour. They got a first version working that is able to do basic actions: step, restart, step into. The challenge was to get to understand the model, and to figure out that primitive: 19 is used for marking that a method should not be debugged. In any case, working with Glamour seemed to work quite smoothly. The code is available in the Glamorous Toolkit. Adrian, did I get it right? :) - Mircea built a new widget for searching multiple categories of items in the same time, similar to spotlight where you enter one string and you get multiple hits from multiple categories. The implementation was spawned from the OBCompletionDialog / OBCompletionRequest and currently it simply provides multiple lists one below the other. The idea is to use this kind of widget to search simultaneously for classes / methods / packages. The code is available in Glamour (Glamour-Morphic-Renderer). The widget can definitely be improved visually, but Mircea already did a nice job. is the widget only for glamour because I think that a widget with search list integrated should be used everywhere? We were discussing with alain to have a look at the one in OB and push it/rewrite it as a core widget Neither the OB nor the Glamour widgets depend on Glamour, so they can be used independently. You just need to take the Request and the Dialog together. ok where is the code? OBCompletionDialog / OBCompletionRequest come with the OB from Pharo 1.2. The way to use it is like: OBCompletionRequest new prompt: 'Find Class'; searchBlock: [ :string | OBCmdFindClass new findClassIn: Smalltalk pattern: string ]; labelBlock: [ :class | class name ]; iconBlock: [ :class | class browserIcon ]; signal. The GLMSpotterRequest / GLMMorphicSpotterDialog are in Glamour-Morphic-Renderer. You can use them like | composite classRequest methodRequest thirdRequest | composite := GLMSpotterRequest new. classRequest := GLMSingleSpotterRequest new prompt: 'Find Class'; searchBlock: [ :string | OBCmdFindClass new findClassIn: Smalltalk pattern: string ]; labelBlock: [ :class | class name ]; iconBlock: [ :class | class browserIcon ]. methodRequest := GLMSingleSpotterRequest new prompt: 'Object Selectors'; searchBlock: [ :string | Object selectors select: [:e| string, '*' match: e asString] ]; labelBlock: [ :e | e ]. thirdRequest := GLMSingleSpotterRequest new prompt: 'Other Selectors'; searchBlock: [ :string | Class selectors select: [:e| string, '*' match: e asString] ]; labelBlock: [ :e | e ]. composite add: classRequest; add: methodRequest; add: thirdRequest; signal Cheers, Doru -- www.tudorgirba.com Reasonable is what we are accustomed with.
Re: [Pharo-project] [Hudson] News
Great work! Doru On 28 Feb 2011, at 18:05, Mariano Martinez Peck wrote: excellent!!! On Mon, Feb 28, 2011 at 2:33 PM, Marcus Denker marcus.den...@inria.fr wrote: Hi, Slow but steady progress on the hudson infrastructure... 1) We have a Mac slave! Alive and kicking, but not doing anything other then an hourly ping https://pharo-ic.lille.inria.fr/hudson/job/Check%20Builder%20Mac/ 2) Cog Unix (both JIT and Stack VM) build. Fully automatic from repository to binary using Pharo 1.3 as the host system. https://pharo-ic.lille.inria.fr/hudson/job/Cog%20Unix%201.3/ https://pharo-ic.lille.inria.fr/hudson/job/Stack%20VM%20Unix/ lots to do... mac build, windows build. Build debug version, build latest stable *and* latest development, run tests... use the generated VM as the base VM for all 1.3 builds, use generated VM for 1.3 One-Click... and so on. 3) There is a build project for Project Sista... Image side for now, work in progress. https://pharo-ic.lille.inria.fr/hudson/job/Sista/ (broken right now) (TODO: We need to build cog-sista) Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. -- www.tudorgirba.com Not knowing how to do something is not an argument for how it cannot be done.
Re: [Pharo-project] Fwd: [ANN] pharo focused sprint - bern, feb 26
Great! Let's give it a try :) Cheers, Doru On 28 Feb 2011, at 22:58, Esteban Lorenzano wrote: Hi, Yes I'm willing to join you to another glamour work day :) Let's say next saturday? best, Esteban El 27/02/2011, a las 11:36a.m., Tudor Girba escribió: Hi, On 27 Feb 2011, at 12:04, Stéphane Ducasse wrote: - Lukas went over the WeakAnnouncements implementation to get the WeakMessageSend working. The code is in PharoTaskForces should we take action on this one? I mean integrating it. It can be integrated, because the base code works in the same way as before. Currently, the solution is implemented through a WeakAnnouncer which subclasses Announcer. I wanted the weak thing to be merged, because the clients of announcements should benefit from the Weak implementation, but Lukas says that he does not trust the Weak support in Pharo and that if you have many WeakAnnouncers it somehow does not scale. ok so ...? So, we need to investigate more :). It would be cool if someone with more knowledge would take a look, too. Igor, would you have a bit of time to look into it? I will probably also give it a look to see how it works in the context of Glamour. I hope that Esteban will join me again. Esteban, what do you say :)? The problem with the current approach is that models have to take an explicit stand of whether they want weak or non weak when instantiating the announcer. Unfortunately, I do have enough technical knowledge for this. It would be cool if someone with better knowledge in this area would take a look. - Lukas worked on getting OB work with the changes in TextMorph from Pharo 1.2. - Adrian, Jorge and Toon worked on implementing a Debugger on top of Glamour. They got a first version working that is able to do basic actions: step, restart, step into. The challenge was to get to understand the model, and to figure out that primitive: 19 is used for marking that a method should not be debugged. In any case, working with Glamour seemed to work quite smoothly. The code is available in the Glamorous Toolkit. Adrian, did I get it right? :) - Mircea built a new widget for searching multiple categories of items in the same time, similar to spotlight where you enter one string and you get multiple hits from multiple categories. The implementation was spawned from the OBCompletionDialog / OBCompletionRequest and currently it simply provides multiple lists one below the other. The idea is to use this kind of widget to search simultaneously for classes / methods / packages. The code is available in Glamour (Glamour-Morphic-Renderer). The widget can definitely be improved visually, but Mircea already did a nice job. is the widget only for glamour because I think that a widget with search list integrated should be used everywhere? We were discussing with alain to have a look at the one in OB and push it/rewrite it as a core widget Neither the OB nor the Glamour widgets depend on Glamour, so they can be used independently. You just need to take the Request and the Dialog together. ok where is the code? OBCompletionDialog / OBCompletionRequest come with the OB from Pharo 1.2. The way to use it is like: OBCompletionRequest new prompt: 'Find Class'; searchBlock: [ :string | OBCmdFindClass new findClassIn: Smalltalk pattern: string ]; labelBlock: [ :class | class name ]; iconBlock: [ :class | class browserIcon ]; signal. The GLMSpotterRequest / GLMMorphicSpotterDialog are in Glamour-Morphic-Renderer. You can use them like | composite classRequest methodRequest thirdRequest | composite := GLMSpotterRequest new. classRequest := GLMSingleSpotterRequest new prompt: 'Find Class'; searchBlock: [ :string | OBCmdFindClass new findClassIn: Smalltalk pattern: string ]; labelBlock: [ :class | class name ]; iconBlock: [ :class | class browserIcon ]. methodRequest := GLMSingleSpotterRequest new prompt: 'Object Selectors'; searchBlock: [ :string | Object selectors select: [:e| string, '*' match: e asString] ]; labelBlock: [ :e | e ]. thirdRequest := GLMSingleSpotterRequest new prompt: 'Other Selectors'; searchBlock: [ :string | Class selectors select: [:e| string, '*' match: e asString] ]; labelBlock: [ :e | e ]. composite add: classRequest; add: methodRequest; add: thirdRequest; signal Cheers, Doru -- www.tudorgirba.com Reasonable is what we are accustomed with. -- www.tudorgirba.com Every thing should have
Re: [Pharo-project] About RPackage
Hi Stef, This was the decisions that two of us (I mean me and you) took :). Categories are mapped one-to-one to RPackages. The reason is that this is the simplest path to replace categories in the system. The second step is to map the current Monticello package to RPackages so that we can load existing Monticello packages. The third step is to provide saving only of individual RPackages. Thus, Monticello should not save multiple RPackages into one Monticello package, but only make it easy to store each one in a separate package. Once this is achieved, we can merge an RPackage with a Monticello package, which means that the package that you see in the image is directly storable in a transparent way. Cheers, Doru On 1 Mar 2011, at 22:44, Stéphane Ducasse wrote: Hi cyrille/doru and others. I do not understand why RPackage organizer packages contains System? In fact all the categories are mapped to packages and I wonder why. I imagine that this is to avoid to have mostSpecific* logic of packageInfo, but it means that in such a case we should merge categories to get back the package we have right now else we will end up with loading/saving problems. Stef -- www.tudorgirba.com Presenting is storytelling.
Re: [Pharo-project] About RPackage
This was the main problem in the original implementation because the logic of the organizer also depended on this. So, we took it out and I find this way better :). Of course, we can create a helper method for compatibility reasons, but no internal logic should depend on this. Cheers, Doru On 1 Mar 2011, at 22:59, Stéphane Ducasse wrote: Another point RPackagenamed: aString | newPackage | newPackage := self new name: aString ;yourself. self organizer registerPackage: newPackage. ^ newPackage does not register the package and this looks suspicion to me. In addition I do not remember the exact logic but the pattern with PackageInfo is that PackageInfo named: #foo creates the package if it does exist PackageInfo classnamed: aString ^ PackageOrganizer default packageNamed: aString ifAbsent: [(self new packageName: aString) register] So do you remember because it may be better to have the same creation protocol. Stef Hi cyrille/doru and others. I do not understand why RPackage organizer packages contains System? In fact all the categories are mapped to packages and I wonder why. I imagine that this is to avoid to have mostSpecific* logic of packageInfo, but it means that in such a case we should merge categories to get back the package we have right now else we will end up with loading/saving problems. Stef -- www.tudorgirba.com Be rather willing to give than demanding to get.
Re: [Pharo-project] About RPackage
Hi, On 2 Mar 2011, at 09:12, Stéphane Ducasse wrote: On Mar 1, 2011, at 11:06 PM, Tudor Girba wrote: This was the main problem in the original implementation because the logic of the organizer also depended on this. So, we took it out and I find this way better :). Ok I do not remember the protocol. we should ask the PackageOrganizer to create a package? or just to register it. The RPackage classnamed: is an internal method used only by the RPackageOrganizer for creating a package. If you want to ensure a package, you should use (I do not like the name :)): RPackageOrganizerregisterPackageNamed: aSymbol ^ packages at: aSymbol asSymbol ifAbsentPut: [RPackage named: aSymbol] You can get to the default organizer via RPackage organizer. So, something like: RPackage organizer registerPackageNamed: 'MyPackage' should do it. I have the impression that making sure that a package is registered wen created makes sense since the client does not have to do it and forget to do it. So in the PackageInfo logic there are two points; - registration - query/creation I have no problem to discard - query/creation So to which of these two aspects are you referring to. In the current RPackage implementation, #named: is a method meant to be used only internally. The problem with tying creation to registration is that you cannot use multiple Organizers easily (this was the reason why we decoupled the two). What we could do is to rename #named: to #newWithName: and have named: be only a compatibility method that does: named: aString ^ RPackage organizer registerPackageNamed: aString Cheers, Doru Stef Of course, we can create a helper method for compatibility reasons, but no internal logic should depend on this. Cheers, Doru On 1 Mar 2011, at 22:59, Stéphane Ducasse wrote: Another point RPackagenamed: aString | newPackage | newPackage := self new name: aString ;yourself. self organizer registerPackage: newPackage. ^ newPackage does not register the package and this looks suspicion to me. In addition I do not remember the exact logic but the pattern with PackageInfo is that PackageInfo named: #foo creates the package if it does exist PackageInfo classnamed: aString ^ PackageOrganizer default packageNamed: aString ifAbsent: [(self new packageName: aString) register] So do you remember because it may be better to have the same creation protocol. Stef Hi cyrille/doru and others. I do not understand why RPackage organizer packages contains System? In fact all the categories are mapped to packages and I wonder why. I imagine that this is to avoid to have mostSpecific* logic of packageInfo, but it means that in such a case we should merge categories to get back the package we have right now else we will end up with loading/saving problems. Stef -- www.tudorgirba.com Be rather willing to give than demanding to get. -- www.tudorgirba.com Being happy is a matter of choice.
Re: [Pharo-project] Glamour-Morphic-Theme package rename?
Hi, The Glamour-Morphic-Theme is part of the Glamour project and was adopted as is in Pharo for traceability reasons. The theme will certainly evolve in the future due to the needs from Glamour. If the package is renamed then also the classes inside should be renamed to not cause clashes with the existing package. Cheers, Doru On 3 Mar 2011, at 11:27, Stéphane Ducasse wrote: The idea is that alain would like to have only one theme but fully parametrized and that we can unify all that. Typically orange should not be a subclass :). Now you are probably right and I want to remove some other not working theme: Pro and a couple of others. On Mar 2, 2011, at 7:43 PM, DougEdmunds wrote: Shouldn't the Glamour-Morphic-Theme package be renamed to fall under Polymorph-Widgets, like the other themes? It seem that otherwise, the package system will get cluttered with individual theme names. I think of the packaging system as most generic to more specific (using the hyphens). Glamour-Morphic-Theme seems to stick out as not following this naming convention. -- View this message in context: http://forum.world.st/Glamour-Morphic-Theme-package-rename-tp3332037p3332037.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. -- www.tudorgirba.com From an abstract enough point of view, any two things are similar.
Re: [Pharo-project] [COTDC] - 24 DockingBarMorph
Until it gets obsolete :) Doru On 5 Mar 2011, at 08:54, Stéphane Ducasse wrote: I love the example in the comment On Mar 4, 2011, at 9:00 AM, laurent laffont wrote: I'm a kind of container which adhere to one edge of the screen. See me in action with: DockingBarMorph new addMorph: (SimpleButtonMorph new label: 'Say hello'; target: [UIManager inform: 'Hello']; actionSelector: #value); addMorph: (SimpleButtonMorph new label: 'Say bonjour'; target: [UIManager inform: 'Bonjour']; actionSelector: #value); addMorph: (SimpleButtonMorph new label: 'Close'; target: [DockingBarMorph allInstances last delete]; actionSelector: #value); adhereToBottom; openInWorld. Laurent Laffont - @lolgzs Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/ On Thu, Mar 3, 2011 at 6:28 PM, laurent laffont laurent.laff...@gmail.com wrote: Today: DockingBarMorph Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest Laurent -- www.tudorgirba.com Every successful trip needs a suitable vehicle.
Re: [Pharo-project] [squeak-dev] Squeak/Pharo/Cuis on Android
Sounds intriguing :) Doru On 4 Mar 2011, at 22:30, Janko Mivšek wrote: .. there is a native Smalltalk on JavaScript VM on the way .. stay tuned! (but not from me .. ;) Such Smalltalk app can be then wrapped in pure Android, iOS etc. app with technology like PhoneGap (http://www.phonegap.com). I'm namely just preparing a presentation titled From Web to Android App for tommorow local MobileCamp:Android http://www.mobilecamp.si/what/ ... Janko On 04. 03. 2011 11:04, Stéphane Ducasse wrote: I would be interested in any attempts to produce native bytecode on java vm for pharo. Now this is the usual equation: money and money or time. JSqueak or Potatos squeak could be also interesting. Stef On Mar 3, 2011, at 11:02 PM, Göran Krampe wrote: On 03/03/2011 03:37 PM, Torsten Bergmann wrote: What is the state of Squeak/Pharo/Cuis for Android tablets and phone? Lots of questions: - what is the state of VM/images? - any comments/hints on devices, speed and memory consumption? - is it worth to buy one to run Smalltalk for own stuff? - anyone written apps with Smalltalk for Android? - is it possible to interface with native stuff. state of touch support, ... Generally speaking, here are my silly notions in this area: - Android is heavily oriented around Dalvik and the libraries for it (Java) - Android will be *the* platform for private computing in the near future IMHO. Yes, I really think so. Android 3.0 looks really hot. - A Squeak/Pharo/Cuis for Android will never be more than a toy unless we can tap into the Dalvik/Java platform. - This means we REALLY need JNIPort or similar projects to work really, really well in order to actually use the libraries in full. ...or we need to get Squeak running inside/on-top-of Dalvik somehow. Weird ideas: - PotatoSqueak is a port of the Squeak VM to java. Run that on Dalvik and hey... - PySqueak using Pypy could probably generate a fast Squeak VM running in java bytecode which possibly also could be run on Dalvik. Both the above approaches would probably make interfacing with Dalvik/Java much simpler. ...or just try using SilverSmalltalk or such. ;) regards, Göran -- www.tudorgirba.com When people care, great things can happen.
Re: [Pharo-project] [Hudson] News
Excellent! Doru On 4 Mar 2011, at 10:33, Marcus Denker wrote: On Feb 28, 2011, at 2:33 PM, Marcus Denker wrote: Hi, Slow but steady progress on the hudson infrastructure... 1) We have a Mac slave! Alive and kicking, but not doing anything other then an hourly ping https://pharo-ic.lille.inria.fr/hudson/job/Check%20Builder%20Mac/ We now can run tests on the mac. e.g: https://pharo-ic.lille.inria.fr/hudson/view/Pharo/job/Pharo%20Core%201.3%20Mac%20tester/ Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. -- www.tudorgirba.com Problem solving should be focused on describing the problem in a way that makes the solution obvious.
Re: [Pharo-project] Pharo-project weekly summary #4
Thanks :) Doru On 5 Mar 2011, at 22:06, Francois Stephany wrote: Hi guys, The summary for this week is out. Please comment if I said something stupid or forgot something. http://articles.tulipemoutarde.be/pharo-mailing-list-weekly-summary-4 See you next week ;) -- www.tudorgirba.com From an abstract enough point of view, any two things are similar.
Re: [Pharo-project] [Pharo-users] Pharocasts: Build a XML browser
Hi, Nice. Just for comparison, I created a counter part demo for the browser building part using Glamour: http://www.tudorgirba.com/blog/simple-xml-browser-with-glamour Cheers, Doru On 6 Mar 2011, at 22:31, laurent laffont wrote: Watch this to learn how to: - get and parse XML - use Polymorph to build a GUI with a tree and text editor - add a button in Pharo IDE to open the XML browser - control when your breakpoints will trigger see http://www.pharocasts.com/2011/03/build-xml-browser.html Laurent Laffont - @lolgzs Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/ -- www.tudorgirba.com Beauty is where we see it.
Re: [Pharo-project] About the sprint saturday 12
Hi Gary, I would have loved to have you around for the Bern sprint, but I did not know that I need to book you :). So: I would like to explicitly book you for the following one :). Cheers, Doru On 7 Mar 2011, at 16:31, Gary Chambers wrote: As before I 'can' be available on IRC if interested... Book now, as with the Bern sprint I had no reply... Regards, Gary - Original Message - From: Stéphane Ducasse stephane.duca...@inria.fr To: Pharo-project@lists.gforge.inria.fr Sent: Monday, March 07, 2011 3:09 PM Subject: Re: [Pharo-project] About the sprint saturday 12 9 in the morning until 17h INRIA is 15 min by tram from the station direct connection. Stef On Mar 7, 2011, at 3:15 PM, Francois Stephany wrote: Hi, At what time do you start/finish ? Is it far from Lille train station ? Cheers, Francois On 03/03/11 17:30, Stéphane Ducasse wrote: 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 -- www.tudorgirba.com There are no old things, there are only old ways of looking at them.
Re: [Pharo-project] [Pharo-users] Pharocasts: Build a XML browser
Thanks :). I finally settled on a set of tools that kind of work at the moment, so indeed, more screencasts will come. Cheers, Doru On 7 Mar 2011, at 18:01, laurent laffont wrote: On Mon, Mar 7, 2011 at 4:47 PM, Tudor Girba tudor.gi...@gmail.com wrote: Hi, Nice. Just for comparison, I created a counter part demo for the browser building part using Glamour: http://www.tudorgirba.com/blog/simple-xml-browser-with-glamour Cool ! I've updated PharoCasts to link on your demo. (oh, and can't wait your screencasts on Moose ;) Laurent. Cheers, Doru On 6 Mar 2011, at 22:31, laurent laffont wrote: Watch this to learn how to: - get and parse XML - use Polymorph to build a GUI with a tree and text editor - add a button in Pharo IDE to open the XML browser - control when your breakpoints will trigger see http://www.pharocasts.com/2011/03/build-xml-browser.html Laurent Laffont - @lolgzs Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/ -- www.tudorgirba.com Beauty is where we see it. -- www.tudorgirba.com From an abstract enough point of view, any two things are similar.
Re: [Pharo-project] [ANN] Cocoa Squeak VM 5.7.4.1 (non-Cog) released
Small steps are way better than no steps :). Thanks for your steady work. Doru On 8 Mar 2011, at 19:33, Esteban Lorenzano wrote: Hi, I'm releasing a version for Cocoa Squeak VM, version 5.7.4.1 This is just a small bugfix version to make OSProcess plugin works. You can download it from here: Squeak 5.7.4.1 (This version includes the OSProcess plugin as an external plugin) yes... small steps, I'm sorry for that. Cheers, Esteban -- www.tudorgirba.com From an abstract enough point of view, any two things are similar.
Re: [Pharo-project] PharoOneClick .lnk file
+1. Doru On 9 Mar 2011, at 10:32, Geert Claes wrote: Torsten Bergmann wrote: I expect a windows user to be more satisfied with a typicall installer that also set up program group, ... and allows also to uninstall. And this installer download is also smaller than the OneClick since Linux/Mac VMs are not necessary. I don't think we need to have a full blown installer which creates a shortcut to the program group with an uninstaller. I would prefer your suggestion to simply put the Pharo.exe on the top level. I like the fact OneClick has Windows, Mac and Linux i none download and I don't think the size is a problem at all. -- View this message in context: http://forum.world.st/PharoOneClick-lnk-file-tp3342350p3343156.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. -- www.tudorgirba.com If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut.
Re: [Pharo-project] [ANN] Cocoa Squeak VM 5.7.4.1 (non-Cog) released
Indeed. This is a game changer. Doru On 9 Mar 2011, at 11:28, Noury Bouraqadi wrote: Thanks Marcus for all the energy you spend on the CI server ! On 9 mars 2011, at 09:31, Marcus Denker wrote: On Mar 9, 2011, at 9:16 AM, Noury Bouraqadi wrote: Thanks Esteban. BTW, I was expecting to find it on hudson server. I think we should have everything gathered there. Not yet. the day has just 24 hours... Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. Noury Bouraqadi http://car.mines-douai.fr/noury -- -6th National Conference on “Control Architecture of Robots” 24-25 may 2011, Grenoble area, France http://car2011.inrialpes.fr/ -19th ESUG International Smalltalk Conference 22-26 August 2011, Edinburgh, UK http://www.esug.org/Conferences/2011 -19èmes Journées Francophones sur les Systèmes Multi-Agents (JFSMA’11) http://www.univ-valenciennes.fr/congres/jfsma2011/ 17-19 Octobre 2011, Valenciennes, France -- www.tudorgirba.com We cannot reach the flow of things unless we let go.
Re: [Pharo-project] petitparser
Hi, The slides I used for today's tutorial on PetitParser can be found here: http://www.slideshare.net/girba/petitparser-at-the-deep-into-smalltalk-school-2011 Cheers, Doru On 10 Mar 2011, at 12:39, Tudor Girba wrote: Hi, To participate in the PetitParser tutorial to take place this afternoon at the Deep into Smalltalk school, you should: - find one or two partners to code with, and - download the latest Moose image containing PetitParser: http://hudson.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/artifact/moose/*zip*/moose.zip Cheers, Doru -- www.tudorgirba.com Value is always contextual. -- www.tudorgirba.com What is more important: To be happy, or to make happy?
Re: [Pharo-project] petitparser
Hi, The slides I used for today's tutorial on PetitParser can be found here: http://www.slideshare.net/girba/petitparser-at-the-deep-into-smalltalk-school-2011 Cheers, Doru On 10 Mar 2011, at 12:39, Tudor Girba wrote: Hi, To participate in the PetitParser tutorial to take place this afternoon at the Deep into Smalltalk school, you should: - find one or two partners to code with, and - download the latest Moose image containing PetitParser: http://hudson.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/artifact/moose/*zip*/moose.zip Cheers, Doru -- www.tudorgirba.com Value is always contextual. -- www.tudorgirba.com What is more important: To be happy, or to make happy?
Re: [Pharo-project] petitparser
Hi Noury, On 11 Mar 2011, at 06:48, Noury Bouraqadi wrote: Hi Doru, Thanx for your great tutorial! For those who had not the chance to attend, I believe that the video will be available some time in the future. Thanks :) Talks were recorded indeed. Doru, could organize a hands on session this afternoon on Glamour. Is that a question? :) But, yes, I would be ready to do one. Cheers, Doru Noury On 11 mars 2011, at 00:16, Tudor Girba wrote: Hi, The slides I used for today's tutorial on PetitParser can be found here: http://www.slideshare.net/girba/petitparser-at-the-deep-into-smalltalk-school-2011 Cheers, Doru On 10 Mar 2011, at 12:39, Tudor Girba wrote: Hi, To participate in the PetitParser tutorial to take place this afternoon at the Deep into Smalltalk school, you should: - find one or two partners to code with, and - download the latest Moose image containing PetitParser: http://hudson.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/artifact/moose/*zip*/moose.zip Cheers, Doru -- www.tudorgirba.com Value is always contextual. -- www.tudorgirba.com What is more important: To be happy, or to make happy? Noury Bouraqadi http://car.mines-douai.fr/noury -- -6th National Conference on “Control Architecture of Robots” 24-25 may 2011, Grenoble area, France http://car2011.inrialpes.fr/ -19th ESUG International Smalltalk Conference 22-26 August 2011, Edinburgh, UK http://www.esug.org/Conferences/2011 -19èmes Journées Francophones sur les Systèmes Multi-Agents (JFSMA’11) http://www.univ-valenciennes.fr/congres/jfsma2011/ 17-19 Octobre 2011, Valenciennes, France -- www.tudorgirba.com Obvious things are difficult to teach.
[Pharo-project] the glamorous toolkit project
Hi, I would like to promote the idea of projects in Pharo. The concept is simple: we should build new infrastructures that go beyond small fixes and that require the concerted work of multiple people over a longer period of time. A project has a clear goal, and is led by someone. That someone is not necessarily the one that writes all the code (like we might tend to do it), but simply one that ensures that the project advances, that the different contributions are integrated, and that things are not left at 90%. I would like to announce the Glamorous Tool project. The goal of this project is to provide a new set of tools for developing with Pharo. It is to be developed on top of Glamour, and it should address at least the followings: - Coder (ex-System Browser) - Debugger - Inspector - Playground (ex-Workspace - it's not called Workspace anymore because I would like to encourage people not to work there) - Chaser (senders, implementors and references) The project spans several topics. For example: - Glamour support - Morphic enhancements: --- Proper TextMorph with keybindings and context sensitiveness --- Collapsable Panes --- Scalable tabs --- Parallel rendering - Suitable models --- RPackage --- Code introspection --- Debugger model - Testing --- Because these tools are so critical, they should be robust --- OB is a good example for the testing part - Usability --- Principle: Spawning a window might be easy, but it is not effective --- Principle: Uniformity --- Principle: Less concepts are better than many - Graphic design of skins and icons - Weak announcements - Performance I will lead it, and you are welcome to participate. The today sprint is a good occasion to take a look. The current code can be found at: Gofer new squeaksource: 'glamoroust'; package: 'ConfigurationOfGlamoroust'; load. (Smalltalk at: #ConfigurationOfGlamoroust) perform: #loadDefault. Cheers, Doru -- www.tudorgirba.com Sometimes the best solution is not the best solution.
Re: [Pharo-project] [Pharo-users] [participants-ecole-mars2011] THANKS a lot for the awesome Deep Smalltalk School
+1 Doru On 12 Mar 2011, at 09:07, Stéphane Ducasse wrote: Thanks mariano. It was cool and I like the hands-on because we are not just taught but we participate and learn. On Mar 11, 2011, at 10:44 PM, Mariano Martinez Peck wrote: Hi all. I am doing quite an effort to have the laptop opened and type some wordsheehhehe after a whole vm hacking week I promise I cannot do more.. I wanted to thanks everybody for the unbelievable Deep Smalltalk School that we had. I really thanks everybody involved: organizers, INRIA, ESUG, EDM and other sponsors, you, etc. Even if some people don't notice, I know that some of you spend a lot of time and energy (instead of using such yout time for something else). I promise it was more than worth it. The school was a success. People come over the world: Canada, USA, Argentina, Norway, Germany, Belgium, Spain, France, etc. We were around 45 persons. Even if I am a VM newbie, I like low level stuff. Sometimes when you go to ESUG, Smalltalks or any other conference, you can see one or two 30-minutes-talks about VM, compilers, etc. But do you image what is a whole week from 9:00 to 18:00 talking about VM, Compiler, Parser, Networking, optimizations, etc ??? It is really cool!!! If there is something like this again in the future, please, consider coming, you won't regret. The best thing is that since we have a lot of hours, we can have not only the theoretical lessons, but also the hands on. So, we were able to: compile CogVM from scratch, implement a Twitter like app, create some petit parsers, optimize some real code, create a minimal Hazelnut image, create a VM plugin, etc So, once again, thanks a lot to everybody involved. Cheers Mariano -- www.tudorgirba.com Presenting is storytelling.
Re: [Pharo-project] [ANN] Cog issue tracker
+1 Just to clarify: The issue tracker was created after a discussion with Elliot this week, in which he asked us to help him create a Google Code for issues related to Cog so that people can participate. Cheers, Doru On 11 Mar 2011, at 00:46, Igor Stasenko wrote: Hello everyone. Without much debate we just created it at [1]. Now there is a separate place for filing issues for Cog VM. I think Cog deserves separate issue tracker, because currently all reports and problems are mainly buried in vm-dev mailing list, and it is hard to tell what is status of one or another issue, which we lately discovered. And such approach definitely won't scale. So, it was a main reason for making this move. Lets help Eliot (and others who involved in development) make activities to be more organized and visible. I'd like to stress that there is nothing inside code.google in particular, which could make its issue tracker serve our needs well. It will work well only if we, as community, organize ourselves and pay attention to collect and put important information there, make it easily accessible, structured and so on.. [1] http://code.google.com/p/cog/ -- Best regards, Igor Stasenko AKA sig. -- www.tudorgirba.com Every thing should have the right to be different.
Re: [Pharo-project] About the sprint saturday 12
Gary, are you around? Cheers, Doru On 8 Mar 2011, at 11:33, Gary Chambers wrote: No, for the Bern sprint. Regards, Gary - Original Message - From: Stéphane Ducasse stephane.duca...@inria.fr To: Pharo-project@lists.gforge.inria.fr Sent: Monday, March 07, 2011 8:11 PM Subject: Re: [Pharo-project] About the sprint saturday 12 you mean for the 12? Stef On Mar 7, 2011, at 5:40 PM, Gary Chambers wrote: As indicated, due to lack of response prior to event I scheduled other activities, unfortunately... Regards, Gary - Original Message - From: Stéphane Ducasse stephane.duca...@inria.fr To: Pharo-project@lists.gforge.inria.fr Sent: Monday, March 07, 2011 4:26 PM Subject: Re: [Pharo-project] About the sprint saturday 12 did you try screen sharing? On Mar 7, 2011, at 5:25 PM, Gary Chambers wrote: Indeed, I'll be on email/IRC#pharo or whatever else is needed then. Regards, Gary - Original Message - From: Stéphane Ducasse stephane.duca...@inria.fr To: Pharo-project@lists.gforge.inria.fr Sent: Monday, March 07, 2011 4:05 PM Subject: Re: [Pharo-project] About the sprint saturday 12 Good. I would like to merge all the polymorph overrides :). With alain we are building a roadmap to move the UI. Stef As before I 'can' be available on IRC if interested... Book now, as with the Bern sprint I had no reply... Regards, Gary - Original Message - From: Stéphane Ducasse stephane.duca...@inria.fr To: Pharo-project@lists.gforge.inria.fr Sent: Monday, March 07, 2011 3:09 PM Subject: Re: [Pharo-project] About the sprint saturday 12 9 in the morning until 17h INRIA is 15 min by tram from the station direct connection. Stef On Mar 7, 2011, at 3:15 PM, Francois Stephany wrote: Hi, At what time do you start/finish ? Is it far from Lille train station ? Cheers, Francois On 03/03/11 17:30, Stéphane Ducasse wrote: 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 -- www.tudorgirba.com If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut.
Re: [Pharo-project] the glamorous toolkit project
Hi Mariano, The idea is indeed to rewrite all the use cases solved by tools in Glamour at the end. However, this does not mean that we will redo those tools like they are now :). Cheers, Doru On 13 Mar 2011, at 11:01, Mariano Martinez Peck wrote: Tudor/Ben, did you think about rewrting the new UI tools like Recent Messages, Finder, etc...using Glamour ? On Sun, Mar 13, 2011 at 1:24 AM, Igor Stasenko siguc...@gmail.com wrote: +1000 Great initiative and most welcomed. And as you said, even if you don't do most, a planing, coordination and bugging people around helps as well :) On 12 March 2011 08:25, Tudor Girba tudor.gi...@gmail.com wrote: Hi, I would like to promote the idea of projects in Pharo. The concept is simple: we should build new infrastructures that go beyond small fixes and that require the concerted work of multiple people over a longer period of time. A project has a clear goal, and is led by someone. That someone is not necessarily the one that writes all the code (like we might tend to do it), but simply one that ensures that the project advances, that the different contributions are integrated, and that things are not left at 90%. I would like to announce the Glamorous Tool project. The goal of this project is to provide a new set of tools for developing with Pharo. It is to be developed on top of Glamour, and it should address at least the followings: - Coder (ex-System Browser) - Debugger - Inspector - Playground (ex-Workspace - it's not called Workspace anymore because I would like to encourage people not to work there) - Chaser (senders, implementors and references) The project spans several topics. For example: - Glamour support - Morphic enhancements: --- Proper TextMorph with keybindings and context sensitiveness --- Collapsable Panes --- Scalable tabs --- Parallel rendering - Suitable models --- RPackage --- Code introspection --- Debugger model - Testing --- Because these tools are so critical, they should be robust --- OB is a good example for the testing part - Usability --- Principle: Spawning a window might be easy, but it is not effective --- Principle: Uniformity --- Principle: Less concepts are better than many - Graphic design of skins and icons - Weak announcements you can make it bold (or what else you do to mark that it is done and ready to be integrated :) - Performance I will lead it, and you are welcome to participate. The today sprint is a good occasion to take a look. The current code can be found at: Gofer new squeaksource: 'glamoroust'; package: 'ConfigurationOfGlamoroust'; load. (Smalltalk at: #ConfigurationOfGlamoroust) perform: #loadDefault. Cheers, Doru -- www.tudorgirba.com Sometimes the best solution is not the best solution. -- Best regards, Igor Stasenko AKA sig. -- www.tudorgirba.com Being happy is a matter of choice.
Re: [Pharo-project] Short summary of new announcement capabilities
Great work! I am so looking forward to use this :). Please keep us posted when we can play with it and how to load it. Cheers, Doru On 13 Mar 2011, at 10:48, Stéphane Ducasse wrote: Thanks a ***LOT*** It is really important for pharo. Stef On Mar 13, 2011, at 2:08 AM, Henrik Sperre Johansen wrote: Barring a few update problems, they changes Igor and I made today should be ready for general review/inclusion shortly. Here's a few points about the most important differences to the current implementation: 1. Now supports action blocs with 0, 1 or 2 arguments (announcement and receiver). This should allows us to: 1.1 Write blocks with strict guarantees for expiry and removal without keeping strong references to announcers in subscriber, by using the announcer arg to unsubscribe if action is invalid. (Not very nice resulting code, but necessary if altering outside-accessible state) 1.2 use suspendWhile: equivalent from blocks where announcer is not kept in context when such protocol is added. 1.3 Not use :ann argument for action blocks in which you don't really care. 1.4 Provide an upgrade path from events by replacing them with 0-arg MessageSend announcements under the hood if we want. (Would requires some nasty bits with objects as announcers though). 2. Support weak subscriptions for message send type of announcement. Block action requires ephemeron support in VM to correctly unsubscribe automatically, and trying to create them currently raises an error. 3. Reify Subscriptions (which are returned by #when:do: and friends), which can be made weak with #makeWeak. However, for thread-safety reasons this is done using #becomeForward:. If weakness can be determined at subscription time, the recommended way would be to use: announcer weak when:send:to: The weak send creates a wrapper which will instantiate the subscription as weak from the get-go. 4. The SubscriptionRegistry is thread-safe, in the sense that add: remove: and deliver: are protected by a Monitor. (so you can remove: in action block without a deadlock, see 1.1). Rather than block for the entire deliver: process, we chose to only protect the copy of subscriptions. This implies that the following may happen: Thread 1 starts delivery of announcement. Thread 2 interrupts after copy is created, then removes a subscription and carries on doing its stuff Thread 1 resumes, and delivers announcement to remaining subscriptions, potentially including that removed by Thread2. Don't think this is likely to be a common scenario where protecting the entire delivery would have made a difference. If you think otherwise, and can provide a good use case, please speak up and we may change it. if you want to browse the changes, they are available for perusal in the changesets attached to: http://code.google.com/p/pharo/issues/detail?id=3814 (Split in two to take care of migrating existing subscriptions) Don't try to load them though, as they depend on changes in other issues, and the comment changes cause errors. Feedback would be appreciated. Cheers, Henry PS. We forgot to include #on:do:for: friends, which allow you to specify another subscriber than the object block belongs to. This is an oversight and will be corrected before inclusion. Just in case you were following Tudor's tweets and were wondering where they had gone. -- www.tudorgirba.com One cannot do more than one can do.
Re: [Pharo-project] the glamorous toolkit project
I think that this is a good idea. Having the Core tools better is definitely a good thing. Furthermore, the nice thing is that we can reuse the Morphic widgets in Glamour. Cheers, Doru On 13 Mar 2011, at 11:09, Stéphane Ducasse wrote: On Mar 13, 2011, at 11:01 AM, Mariano Martinez Peck wrote: Tudor/Ben, did you think about rewrting the new UI tools like Recent Messages, Finder, etc...using Glamour ? With Ben we are targeting removing StringHolder, so we will rewrite some tools (but not in Glamour) to make sure that we can work without glamour and make sure that we can get rid of StringHolder and friends. In parallel if people make Glamour working well and fully then at some point it could be the ide for Pharo but we need some fallbacks and we will be working on that with Ben. Stef On Sun, Mar 13, 2011 at 1:24 AM, Igor Stasenko siguc...@gmail.com wrote: +1000 Great initiative and most welcomed. And as you said, even if you don't do most, a planing, coordination and bugging people around helps as well :) On 12 March 2011 08:25, Tudor Girba tudor.gi...@gmail.com wrote: Hi, I would like to promote the idea of projects in Pharo. The concept is simple: we should build new infrastructures that go beyond small fixes and that require the concerted work of multiple people over a longer period of time. A project has a clear goal, and is led by someone. That someone is not necessarily the one that writes all the code (like we might tend to do it), but simply one that ensures that the project advances, that the different contributions are integrated, and that things are not left at 90%. I would like to announce the Glamorous Tool project. The goal of this project is to provide a new set of tools for developing with Pharo. It is to be developed on top of Glamour, and it should address at least the followings: - Coder (ex-System Browser) - Debugger - Inspector - Playground (ex-Workspace - it's not called Workspace anymore because I would like to encourage people not to work there) - Chaser (senders, implementors and references) The project spans several topics. For example: - Glamour support - Morphic enhancements: --- Proper TextMorph with keybindings and context sensitiveness --- Collapsable Panes --- Scalable tabs --- Parallel rendering - Suitable models --- RPackage --- Code introspection --- Debugger model - Testing --- Because these tools are so critical, they should be robust --- OB is a good example for the testing part - Usability --- Principle: Spawning a window might be easy, but it is not effective --- Principle: Uniformity --- Principle: Less concepts are better than many - Graphic design of skins and icons - Weak announcements you can make it bold (or what else you do to mark that it is done and ready to be integrated :) - Performance I will lead it, and you are welcome to participate. The today sprint is a good occasion to take a look. The current code can be found at: Gofer new squeaksource: 'glamoroust'; package: 'ConfigurationOfGlamoroust'; load. (Smalltalk at: #ConfigurationOfGlamoroust) perform: #loadDefault. Cheers, Doru -- www.tudorgirba.com Sometimes the best solution is not the best solution. -- Best regards, Igor Stasenko AKA sig. -- www.tudorgirba.com Some battles are better lost than fought.
Re: [Pharo-project] The current status of OSProcess
+10 We definitely both of them in Moose. Doru On 13 Mar 2011, at 10:46, Stéphane Ducasse wrote: +1 OSProcess is really important for us. Like a good FFI Stef On Mar 13, 2011, at 1:11 AM, Igor Stasenko wrote: On 13 March 2011 00:19, David T. Lewis le...@mail.msen.com wrote: Hi Igor, I think it is good to make OSPP (and AioPlugin and XDisplayControlPlugin where appropriate) available in all distributed VMs, but in some applications they provide too much access to the operating system, so it is good to have them as external modules so that people who do not want them on the system can delete the modules. So I think it is best to treat it like FFI, it is there if you want it but can be removed if you are doing some sort of application where the user should not have easy access to the OS functions. Well, i think for making a secure 'appliance' sort of, a better approach to not rely on prebuilt VM , but build your own where you can always decide what is secure enough and what's not, and should be removed/disabled. Btw, we discussed a bit of this today with Henrik, and first thing i think people should do, in order to make it more secure is to disable external module loading mechanism. Declaring that standard VM is more secure if you don't ship it with _external_ modules (like FFI) sounds like a joke. So, what i'd like to ask is, that if everyone feel a day-to-day need for using things like FFI or OSProcessPlugin we should make it available by default and out of the box. And for those, who concerned with low security there is always an options to improve it, like hiring people to develop a custom VM based on default one, where all security problems is addressed properly. So, i don't see why we should constrain ourselves with things we use and need, only because in eyes of someone it doesn't looks secure enough. Dave -- Best regards, Igor Stasenko AKA sig. -- www.tudorgirba.com Obvious things are difficult to teach.
Re: [Pharo-project] Pharo mailing list weekly summary #5
+1 Doru On 13 Mar 2011, at 09:31, laurent laffont wrote: Thanks François, very useful. Laurent. On Sun, Mar 13, 2011 at 1:35 AM, Igor Stasenko siguc...@gmail.com wrote: Thanks for overview. Works for me. I found that i missed couple of important topics this week. .. ohh there is too much mails :) On 12 March 2011 21:19, Francois Stephany tulipe.mouta...@gmail.com wrote: Sure, I'll add the date range next week ;) Of course, some threads span on 2 or 3 periods. On 12/03/11 19:49, Noury Bouraqadi wrote: I'd rather prefer the actual date such as: 7-13 march 2011 Thanx François any way. On 12 mars 2011, at 18:14, Geert Claes wrote: Hi Francois, Excellent job again. Just one suggestion, can we use the actual week number e.g. Pharo summary week 10, 2011? -- View this message in context: http://forum.world.st/Pharo-mailing-list-weekly-summary-5-tp3350331p3350535.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. -- Best regards, Igor Stasenko AKA sig. -- www.tudorgirba.com Every successful trip needs a suitable vehicle.
Re: [Pharo-project] Fixed Width Font for COG
I would be interested in the result as well. Is there anyone working/experimenting with this? Cheers, Doru On 12 Mar 2011, at 23:54, Henrik Sperre Johansen wrote: Den 12.03.2011 23:25, skrev Igor Stasenko: On 12 March 2011 15:12, Camillo Bruni camillo.br...@inria.fr wrote: Does anyone know what the proceedure is to include a new font directly in the image without plugin support? eg Issue 3809 using DejaVu Mono in the image i don't think that possible because to rasterize fonts you need a renderer Not sure if you misread what Camillo wrote as import directly into image, but including additional fonts are certainly possible :) As can be seen in the thread Damien linked in the issue, Juan did not provide any easily reproducable process for how he did it for the normal Deja Vu fonts though, so some experimentation would be necessary to achieve good results. Cheers, Henry PS: http://forum.world.st/Is-it-possible-to-setup-Russian-fonts-in-Pharo-Cog-VM-td3329185.html#a3332820 , you can include the FT2Plugin from a standard vm somewhere Cog will find it, and it should work. Really should make this a FAQ entry :) -- www.tudorgirba.com What we can governs what we wish.
Re: [Pharo-project] Do you want to add the background picture to the image like we did with Pharo 1.1 ?
I vote against using a picture as a background. Doru On 13 Mar 2011, at 18:00, Noury Bouraqadi wrote: Yes. This is why I sent a picture I took my self of a public place. So, no pb with the licence since I signed the agreement :-) But anyway, if it's too late, then we can put this on the todo for 1.3. BTW, I don't remember if the agreement covers all materials or only code. Noury On 13 mars 2011, at 16:37, Serge Stinckwich wrote: The problem is to use pictures with the suitable free licence ... i prefer to use the previous gray background and some colors. Envoyé de mon iPad Le 13 mars 2011 à 03:40, Noury Bouraqadi bouraq...@gmail.com a écrit : On 13 mars 2011, at 07:59, Guillermo Polito wrote: Forgot the faded one? Like the idea :) Here it is. But, I prefer the other one with saturated colors. tentativeBackgroundPharo1.2.jpeg On Sun, Mar 13, 2011 at 3:35 AM, Noury Bouraqadi bouraq...@gmail.com wrote: Just got an idea. What about using a picture of some physical pharo. On every new version we can change the pharo. I'm not good at graphics but here is a sketch of the idea using a picture of mine (in small size). I put the original and the faded one. Noury On 12 mars 2011, at 23:39, Igor Stasenko wrote: On 12 March 2011 21:15, Noury Bouraqadi bouraq...@gmail.com wrote: +1. I suggest to change the background for every new version. Also put the version number next the logo. +1 now the question what background should be used by 1.2 release? On 12 mars 2011, at 20:16, Mariano Martinez Peck wrote: If I could decide, I would vote for it :) I like it. If you agree, then it is very easy to add to hudson, just modify (marcus?) the Pharo.st used to build the images to do something like this: World backgroundImage: (ImageReadWriter formFromFileNamed: 'pharoBackground.png') layout: #scaled. I attach here the picture used. Cheers Mariano pharoBackground.png Noury Bouraqadi http://car.mines-douai.fr/noury -- -6th National Conference on “Control Architecture of Robots” 24-25 may 2011, Grenoble area, France http://car2011.inrialpes.fr/ -19th ESUG International Smalltalk Conference 22-26 August 2011, Edinburgh, UK http://www.esug.org/Conferences/2011 -19èmes Journées Francophones sur les Systèmes Multi-Agents (JFSMA’11) http://www.univ-valenciennes.fr/congres/jfsma2011/ 17-19 Octobre 2011, Valenciennes, France -- Best regards, Igor Stasenko AKA sig. Noury Bouraqadi http://car.mines-douai.fr/noury -- -6th National Conference on “Control Architecture of Robots” 24-25 may 2011, Grenoble area, France http://car2011.inrialpes.fr/ -19th ESUG International Smalltalk Conference 22-26 August 2011, Edinburgh, UK http://www.esug.org/Conferences/2011 -19èmes Journées Francophones sur les Systèmes Multi-Agents (JFSMA’11) http://www.univ-valenciennes.fr/congres/jfsma2011/ 17-19 Octobre 2011, Valenciennes, France Noury Bouraqadi http://car.mines-douai.fr/noury -- -6th National Conference on “Control Architecture of Robots” 24-25 may 2011, Grenoble area, France http://car2011.inrialpes.fr/ -19th ESUG International Smalltalk Conference 22-26 August 2011, Edinburgh, UK http://www.esug.org/Conferences/2011 -19èmes Journées Francophones sur les Systèmes Multi-Agents (JFSMA’11) http://www.univ-valenciennes.fr/congres/jfsma2011/ 17-19 Octobre 2011, Valenciennes, France Noury Bouraqadi http://car.mines-douai.fr/noury -- -6th National Conference on “Control Architecture of Robots” 24-25 may 2011, Grenoble area, France http://car2011.inrialpes.fr/ -19th ESUG International Smalltalk Conference 22-26 August 2011, Edinburgh, UK http://www.esug.org/Conferences/2011 -19èmes Journées Francophones sur les Systèmes Multi-Agents (JFSMA’11) http://www.univ-valenciennes.fr/congres/jfsma2011/ 17-19 Octobre 2011, Valenciennes, France -- www.tudorgirba.com Presenting is storytelling.
Re: [Pharo-project] [ANN] More on Keymappings
Excellent initiative Camillo! Regarding multiple packages: Having multiple packages limits the conflicts, and saving them individually (for now) it's a small price to pay. Cheers, Doru On 13 Mar 2011, at 22:28, Camillo Bruni wrote: furthermore, lets use a single repos/package (or whatever this is called in MC). I do not like to commit 3 times while refactoring. later on we can still split it up so people can actually decide on what to load. camillo On 2011-03-13, at 22:20, Camillo Bruni wrote: I can push my changes. but I don't think we should rely too much on your old code. Im trying to keep the structure of the classes, that was already very nice IMO. I manly adress the following issues: - use of arrays as result (dedicatet results object) - string to match the shortcuts with the incoming keyboard event (dropped all of that and started to work on tests to use the shortcuts directly) - weird event matching directly on morph (simplified and using a recursive function call now) - horrible unreadable variable names (wherever I started I tried to put long names to make the code readable) I suggest we can work together on the new code base, since the interface will stay fairly compatible. camillo On 2011-03-13, at 22:08, Guillermo Polito wrote: Camillo, I was fixing some tests and going to refactor some ugly parts of the package. Is there a way to join forces so we don't step into the other work? Guille On Sun, Mar 13, 2011 at 6:04 PM, Camillo Bruni camillo.br...@inria.frwrote: I started on the last Lille sprint a complete rewrite of the Keymapping package. As of now it is not yet functional but the growing test-coverage should help to solve this issue. m(^_-)m camillo On 2011-03-03, at 15:16, Camillo Bruni wrote: Right, the stable has a preconditio which limits it to pharo 1.2. Furthermore the initialization code seems to be incompatible as it uses to:do: on Character which is AFAIK not implemented in the core image Pharo 1.3. Hence apply the following changes: KMKeyEvent class initializeControlSequences ... $a asciiValue to: $z asciiValue do: [:each | d add: each asCharacter - (each - $a asciiValue + 1)]. ... then it should work. m(^_-)m camillo On 2011-03-03, at 09:25, Tudor Girba wrote: Hi, I am very interested to get Keymapping integrated into Glamour. Could someone help me to load it? I tried: - in Pharo 1.2: Gofer it squeaksource: 'Keymapping'; package: 'ConfigurationOfKeymapping'; load. (ConfigurationOfKeymapping project version: #stable) load - in Pharo 1.3: Gofer it squeaksource: 'Keymapping'; package: 'ConfigurationOfKeymapping'; load. (ConfigurationOfKeymapping project version: '1.5') load Cheers, Doru On 27 Feb 2011, at 09:59, Tudor Girba wrote: I also I cannot load Keymapping 1.5 in Pharo 1.2. I get DNU for Character+. This is due to an initialization in KMKeyEvent (see the attached debug log). I did the followings: Gofer it squeaksource: 'Keymapping'; package: 'ConfigurationOfKeymapping'; load. (ConfigurationOfKeymapping project version: #stable) load Am I missing something, or is this version not supposed to work in Pharo 1.2? Cheers, Doru PharoDebug.log On 26 Feb 2011, at 21:08, Francisco Ortiz Peñaloza wrote: You're telling me that if i do a clean installation of 1.5 it would work? Thanks in advance, Francisco On Sat, Feb 26, 2011 at 3:50 PM, Guillermo Polito guillermopol...@gmail.com wrote: Mmm, If you had 1.4 and updated to 1.5, you will have some problems because I did some refactorings on that... :/. On Sat, Feb 26, 2011 at 10:12 AM, Francisco Ortiz Peñaloza patchi...@gmail.com wrote: Guille i was using 1.4 and worked excellent, just tried 1.5 and on every stroke i made i've got a DNU on #realtarget Installed on last PharoCore 1.2, should i try it on 1.3? Great work, Fran On Sat, Feb 26, 2011 at 5:29 AM, laurent laffont laurent.laff...@gmail.com wrote: On Sat, Feb 26, 2011 at 5:42 AM, Guillermo Polito guillermopol...@gmail.com wrote: What do we have now? - Can provide settings for a set of morphs - Can provide settings for a TextEditors (Smalltalk editor and related) - Settings integration I added some methods to the Settings Tree Builder in order to avoid references from the users code. - I ran Slint over it and cleaned it a lot more :). ( And learnt that Slint is there :P ) More info in here: http://guilleel3.blogspot.com/ A new blog, cool ! Can I have Emacs-like keybinding in code editor, to switch browser, ... ? Laurent. Guille -- www.tudorgirba.com Every thing has its own flow. -- www.tudorgirba.com Every thing should have the right to be different. -- www.tudorgirba.com Value is always contextual.
Re: [Pharo-project] Fixed Width Font for COG
Which plugin exactly and where to copy it from? :) Doru On 13 Mar 2011, at 22:11, Camillo Bruni wrote: just copying over the plugin worked perfectly. nevertheless I think we should include the two fonts directly in the image... though I wont have time to solve this the next few weeks. basically we need to write out each character of the ascii range into an image and store the x offset of each character in an array. camillo On 2011-03-13, at 17:41, Tudor Girba wrote: I would be interested in the result as well. Is there anyone working/experimenting with this? Cheers, Doru On 12 Mar 2011, at 23:54, Henrik Sperre Johansen wrote: Den 12.03.2011 23:25, skrev Igor Stasenko: On 12 March 2011 15:12, Camillo Bruni camillo.br...@inria.fr wrote: Does anyone know what the proceedure is to include a new font directly in the image without plugin support? eg Issue 3809 using DejaVu Mono in the image i don't think that possible because to rasterize fonts you need a renderer Not sure if you misread what Camillo wrote as import directly into image, but including additional fonts are certainly possible :) As can be seen in the thread Damien linked in the issue, Juan did not provide any easily reproducable process for how he did it for the normal Deja Vu fonts though, so some experimentation would be necessary to achieve good results. Cheers, Henry PS: http://forum.world.st/Is-it-possible-to-setup-Russian-fonts-in-Pharo-Cog-VM-td3329185.html#a3332820 , you can include the FT2Plugin from a standard vm somewhere Cog will find it, and it should work. Really should make this a FAQ entry :) -- www.tudorgirba.com What we can governs what we wish. -- www.tudorgirba.com Next time you see your life passing by, say 'hi' and get to know her.
Re: [Pharo-project] the glamorous toolkit project
Thanks, Esteban. Jorge did a nice job at improving it to handle special objects. There are still a couple of situations left, but it is already reliable. Cheers, Doru On 13 Mar 2011, at 19:33, Esteban Lorenzano wrote: wow GTInspector is really great :) gamorous tools are becoming very interesting... keep going that way! I do believe in the near future GT can replace OB as our default IDE, if we continue improving like this :) cheers, Esteban El 13/03/2011, a las 10:34a.m., Marcus Denker escribió: On Mar 13, 2011, at 2:05 PM, Tudor Girba wrote: I think that this is a good idea. Having the Core tools better is definitely a good thing. One thing to keep in mind is that we need (ass soon as possible) to have *one* set of tools... with OB we have seen that we have just not the manpower to in parallel maintain two sets of tools (Core vs. Dev). The notion of Core Tools is broken. Whichever tools we do in the future need to *replace* the old tools. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. -- www.tudorgirba.com Not knowing how to do something is not an argument for how it cannot be done.
Re: [Pharo-project] [ANN] More on Keymappings
I saw :). Just two questions: - Is the ConfigurationOfKeymapping updated? - Is it already usable? Cheers, Doru On 14 Mar 2011, at 15:15, Camillo Bruni wrote: I pushed everying into a single Keymapping package for now. As soon as there is full functionality we should separate it again. camillo On 2011-03-13, at 22:40, Tudor Girba wrote: Excellent initiative Camillo! Regarding multiple packages: Having multiple packages limits the conflicts, and saving them individually (for now) it's a small price to pay. Cheers, Doru On 13 Mar 2011, at 22:28, Camillo Bruni wrote: furthermore, lets use a single repos/package (or whatever this is called in MC). I do not like to commit 3 times while refactoring. later on we can still split it up so people can actually decide on what to load. camillo On 2011-03-13, at 22:20, Camillo Bruni wrote: I can push my changes. but I don't think we should rely too much on your old code. Im trying to keep the structure of the classes, that was already very nice IMO. I manly adress the following issues: - use of arrays as result (dedicatet results object) - string to match the shortcuts with the incoming keyboard event (dropped all of that and started to work on tests to use the shortcuts directly) - weird event matching directly on morph (simplified and using a recursive function call now) - horrible unreadable variable names (wherever I started I tried to put long names to make the code readable) I suggest we can work together on the new code base, since the interface will stay fairly compatible. camillo On 2011-03-13, at 22:08, Guillermo Polito wrote: Camillo, I was fixing some tests and going to refactor some ugly parts of the package. Is there a way to join forces so we don't step into the other work? Guille On Sun, Mar 13, 2011 at 6:04 PM, Camillo Bruni camillo.br...@inria.frwrote: I started on the last Lille sprint a complete rewrite of the Keymapping package. As of now it is not yet functional but the growing test-coverage should help to solve this issue. m(^_-)m camillo On 2011-03-03, at 15:16, Camillo Bruni wrote: Right, the stable has a preconditio which limits it to pharo 1.2. Furthermore the initialization code seems to be incompatible as it uses to:do: on Character which is AFAIK not implemented in the core image Pharo 1.3. Hence apply the following changes: KMKeyEvent class initializeControlSequences ... $a asciiValue to: $z asciiValue do: [:each | d add: each asCharacter - (each - $a asciiValue + 1)]. ... then it should work. m(^_-)m camillo On 2011-03-03, at 09:25, Tudor Girba wrote: Hi, I am very interested to get Keymapping integrated into Glamour. Could someone help me to load it? I tried: - in Pharo 1.2: Gofer it squeaksource: 'Keymapping'; package: 'ConfigurationOfKeymapping'; load. (ConfigurationOfKeymapping project version: #stable) load - in Pharo 1.3: Gofer it squeaksource: 'Keymapping'; package: 'ConfigurationOfKeymapping'; load. (ConfigurationOfKeymapping project version: '1.5') load Cheers, Doru On 27 Feb 2011, at 09:59, Tudor Girba wrote: I also I cannot load Keymapping 1.5 in Pharo 1.2. I get DNU for Character+. This is due to an initialization in KMKeyEvent (see the attached debug log). I did the followings: Gofer it squeaksource: 'Keymapping'; package: 'ConfigurationOfKeymapping'; load. (ConfigurationOfKeymapping project version: #stable) load Am I missing something, or is this version not supposed to work in Pharo 1.2? Cheers, Doru PharoDebug.log On 26 Feb 2011, at 21:08, Francisco Ortiz Peñaloza wrote: You're telling me that if i do a clean installation of 1.5 it would work? Thanks in advance, Francisco On Sat, Feb 26, 2011 at 3:50 PM, Guillermo Polito guillermopol...@gmail.com wrote: Mmm, If you had 1.4 and updated to 1.5, you will have some problems because I did some refactorings on that... :/. On Sat, Feb 26, 2011 at 10:12 AM, Francisco Ortiz Peñaloza patchi...@gmail.com wrote: Guille i was using 1.4 and worked excellent, just tried 1.5 and on every stroke i made i've got a DNU on #realtarget Installed on last PharoCore 1.2, should i try it on 1.3? Great work, Fran On Sat, Feb 26, 2011 at 5:29 AM, laurent laffont laurent.laff...@gmail.com wrote: On Sat, Feb 26, 2011 at 5:42 AM, Guillermo Polito guillermopol...@gmail.com wrote: What do we have now? - Can provide settings for a set of morphs - Can provide settings for a TextEditors (Smalltalk editor and related) - Settings integration I added some methods to the Settings Tree Builder in order to avoid references from the users code. - I ran Slint over it and cleaned it a lot more :). ( And learnt that Slint is there :P ) More info in here: http://guilleel3.blogspot.com/ A new blog, cool ! Can I have Emacs-like keybinding in code
Re: [Pharo-project] [update 1.2 Core] #12341
Excellent! Doru On 14 Mar 2011, at 13:56, Marcus Denker wrote: 12341 - Release 1.2 (Core) -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. -- www.tudorgirba.com Presenting is storytelling.
Re: [Pharo-project] the glamorous toolkit project
Hi Mariano, Thanks for the suggestions. As I said, you are welcome to participate. It does not have to be much. You can just spend a bit of time to learn Glamour and then play 15 minutes per day :). Cheers, Doru On 14 Mar 2011, at 19:34, Mariano Martinez Peck wrote: Hi Tudor? do you want to succeed? Do a kind of OB but with multiple selection :) I would like to remove, for example, several methods together... cheers mariano On Sun, Mar 13, 2011 at 10:45 PM, Tudor Girba tudor.gi...@gmail.com wrote: Thanks, Esteban. Jorge did a nice job at improving it to handle special objects. There are still a couple of situations left, but it is already reliable. Cheers, Doru On 13 Mar 2011, at 19:33, Esteban Lorenzano wrote: wow GTInspector is really great :) gamorous tools are becoming very interesting... keep going that way! I do believe in the near future GT can replace OB as our default IDE, if we continue improving like this :) cheers, Esteban El 13/03/2011, a las 10:34a.m., Marcus Denker escribió: On Mar 13, 2011, at 2:05 PM, Tudor Girba wrote: I think that this is a good idea. Having the Core tools better is definitely a good thing. One thing to keep in mind is that we need (ass soon as possible) to have *one* set of tools... with OB we have seen that we have just not the manpower to in parallel maintain two sets of tools (Core vs. Dev). The notion of Core Tools is broken. Whichever tools we do in the future need to *replace* the old tools. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. -- www.tudorgirba.com Not knowing how to do something is not an argument for how it cannot be done. -- www.tudorgirba.com From an abstract enough point of view, any two things are similar.
[Pharo-project] Keymapping development issues
Hi, It seems to me that there are problems due to the merging of Keymapping sub packages into one Keymapping package: - first, camillo seems to publish in Keymapping, while Guillermo publishes in Keymapping-*. This means that one or the other will most certainly lose code. - second, the version published by Camillo reached Keymapping-CamilloBruni.3, but there already were versions that reached Keymapping-cds.113, which makes Monticello list the new commits by Camillo at the bottom Would it be possible if you two would get synchronized? Also, ConfigurationOfKeymapping is still broken: - loading (self project version: '1.5') load still raises the Character+ problem due to the initialization - however, loading (self project version: '1.5-baseline') load works because it takes the new versions into account Would it be possible to update the configuration? Cheers, Doru On 14 Mar 2011, at 15:20, Camillo Bruni wrote: On 2011-03-14, at 15:17, Tudor Girba wrote: I saw :). Just two questions: - Is the ConfigurationOfKeymapping updated? that I pushed to the existing branch - Is it already usable? not yet, didn't have too much time so far, but the basic tests are working. the interface will stay the same, but the internals will be much cleaner and more explicit Cheers, Doru On 14 Mar 2011, at 15:15, Camillo Bruni wrote: I pushed everying into a single Keymapping package for now. As soon as there is full functionality we should separate it again. camillo On 2011-03-13, at 22:40, Tudor Girba wrote: Excellent initiative Camillo! Regarding multiple packages: Having multiple packages limits the conflicts, and saving them individually (for now) it's a small price to pay. Cheers, Doru On 13 Mar 2011, at 22:28, Camillo Bruni wrote: furthermore, lets use a single repos/package (or whatever this is called in MC). I do not like to commit 3 times while refactoring. later on we can still split it up so people can actually decide on what to load. camillo On 2011-03-13, at 22:20, Camillo Bruni wrote: I can push my changes. but I don't think we should rely too much on your old code. Im trying to keep the structure of the classes, that was already very nice IMO. I manly adress the following issues: - use of arrays as result (dedicatet results object) - string to match the shortcuts with the incoming keyboard event (dropped all of that and started to work on tests to use the shortcuts directly) - weird event matching directly on morph (simplified and using a recursive function call now) - horrible unreadable variable names (wherever I started I tried to put long names to make the code readable) I suggest we can work together on the new code base, since the interface will stay fairly compatible. camillo On 2011-03-13, at 22:08, Guillermo Polito wrote: Camillo, I was fixing some tests and going to refactor some ugly parts of the package. Is there a way to join forces so we don't step into the other work? Guille On Sun, Mar 13, 2011 at 6:04 PM, Camillo Bruni camillo.br...@inria.frwrote: I started on the last Lille sprint a complete rewrite of the Keymapping package. As of now it is not yet functional but the growing test-coverage should help to solve this issue. m(^_-)m camillo On 2011-03-03, at 15:16, Camillo Bruni wrote: Right, the stable has a preconditio which limits it to pharo 1.2. Furthermore the initialization code seems to be incompatible as it uses to:do: on Character which is AFAIK not implemented in the core image Pharo 1.3. Hence apply the following changes: KMKeyEvent class initializeControlSequences ... $a asciiValue to: $z asciiValue do: [:each | d add: each asCharacter - (each - $a asciiValue + 1)]. ... then it should work. m(^_-)m camillo On 2011-03-03, at 09:25, Tudor Girba wrote: Hi, I am very interested to get Keymapping integrated into Glamour. Could someone help me to load it? I tried: - in Pharo 1.2: Gofer it squeaksource: 'Keymapping'; package: 'ConfigurationOfKeymapping'; load. (ConfigurationOfKeymapping project version: #stable) load - in Pharo 1.3: Gofer it squeaksource: 'Keymapping'; package: 'ConfigurationOfKeymapping'; load. (ConfigurationOfKeymapping project version: '1.5') load Cheers, Doru On 27 Feb 2011, at 09:59, Tudor Girba wrote: I also I cannot load Keymapping 1.5 in Pharo 1.2. I get DNU for Character+. This is due to an initialization in KMKeyEvent (see the attached debug log). I did the followings: Gofer it squeaksource: 'Keymapping'; package: 'ConfigurationOfKeymapping'; load. (ConfigurationOfKeymapping project version: #stable) load Am I missing something, or is this version not supposed to work in Pharo 1.2? Cheers, Doru PharoDebug.log On 26 Feb 2011, at 21:08, Francisco Ortiz Peñaloza wrote: You're telling me that if i do a clean
Re: [Pharo-project] What a mess
Apparently, it is not broken at all. Like Torsten said, you have to explicitly mention that you want the file: if you want to specify an absolute path. Cheers, Doru On 16 Mar 2011, at 16:14, Stéphane Ducasse wrote: I trying to figure out how command-line arguments are passed to image... and this is complete mess. what if this is broken don't fix it ;D Yes we will fix that tooo I cannot determine why on Windoze, a script argument passed in command line is ignored. -- Best regards, Igor Stasenko AKA sig. -- www.tudorgirba.com Presenting is storytelling.
Re: [Pharo-project] [ANN 1.2] prebuilt core 1.2 final
+1 Doru On 18 Mar 2011, at 08:07, Marcus Denker wrote: On Mar 18, 2011, at 8:04 AM, Henrik Sperre Johansen wrote: And nobody ever unloaded anything from Core. Marcus I thought the general idea was to remove SimpleMorphic before releases? Think I read so in an issue, or on the list. Yes, but it was not done for 1.2 and 1.2 is *finished*. If we want to do that, we need to do that *not after the release is released* but before. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. -- www.tudorgirba.com Beauty is where we see it.
Re: [Pharo-project] Keymapping development issues
Great. Please keep us posted. Cheers, Doru On 18 Mar 2011, at 18:52, Camillo Bruni wrote: Ok, I think I will retrofit my tryout on top of the existing work of guille. camillo On 2011-03-15, at 13:29, Guillermo Polito wrote: Hi! On Tue, Mar 15, 2011 at 3:18 AM, Tudor Girba tudor.gi...@gmail.com wrote: Hi, It seems to me that there are problems due to the merging of Keymapping sub packages into one Keymapping package: - first, camillo seems to publish in Keymapping, while Guillermo publishes in Keymapping-*. This means that one or the other will most certainly lose code. Actually, we had a couple of problems: - I saw the changes made by Camillo, but his version is broken and it was not working. - I couldn't merge some changes I did because we did not get really synchronized at first. - We want to change the same things, but we don't like each other's solution nor process of development :$. - second, the version published by Camillo reached Keymapping-CamilloBruni.3, but there already were versions that reached Keymapping-cds.113, which makes Monticello list the new commits by Camillo at the bottom Would it be possible if you two would get synchronized? Also, ConfigurationOfKeymapping is still broken: - loading (self project version: '1.5') load still raises the Character+ problem due to the initialization - however, loading (self project version: '1.5-baseline') load works because it takes the new versions into account Would it be possible to update the configuration? I created development version 1.6, which contains a lot of refactorings already. It's preety better. I removed the string matching between shortcuts, and the ugly selectors to look at the match of a mapping. I'd like it to reviewed... Cheers, Doru Cheers, Guille On 14 Mar 2011, at 15:20, Camillo Bruni wrote: On 2011-03-14, at 15:17, Tudor Girba wrote: I saw :). Just two questions: - Is the ConfigurationOfKeymapping updated? that I pushed to the existing branch - Is it already usable? not yet, didn't have too much time so far, but the basic tests are working. the interface will stay the same, but the internals will be much cleaner and more explicit Cheers, Doru On 14 Mar 2011, at 15:15, Camillo Bruni wrote: I pushed everying into a single Keymapping package for now. As soon as there is full functionality we should separate it again. camillo On 2011-03-13, at 22:40, Tudor Girba wrote: Excellent initiative Camillo! Regarding multiple packages: Having multiple packages limits the conflicts, and saving them individually (for now) it's a small price to pay. Cheers, Doru On 13 Mar 2011, at 22:28, Camillo Bruni wrote: furthermore, lets use a single repos/package (or whatever this is called in MC). I do not like to commit 3 times while refactoring. later on we can still split it up so people can actually decide on what to load. camillo On 2011-03-13, at 22:20, Camillo Bruni wrote: I can push my changes. but I don't think we should rely too much on your old code. Im trying to keep the structure of the classes, that was already very nice IMO. I manly adress the following issues: - use of arrays as result (dedicatet results object) - string to match the shortcuts with the incoming keyboard event (dropped all of that and started to work on tests to use the shortcuts directly) - weird event matching directly on morph (simplified and using a recursive function call now) - horrible unreadable variable names (wherever I started I tried to put long names to make the code readable) I suggest we can work together on the new code base, since the interface will stay fairly compatible. camillo On 2011-03-13, at 22:08, Guillermo Polito wrote: Camillo, I was fixing some tests and going to refactor some ugly parts of the package. Is there a way to join forces so we don't step into the other work? Guille On Sun, Mar 13, 2011 at 6:04 PM, Camillo Bruni camillo.br...@inria.frwrote: I started on the last Lille sprint a complete rewrite of the Keymapping package. As of now it is not yet functional but the growing test-coverage should help to solve this issue. m(^_-)m camillo On 2011-03-03, at 15:16, Camillo Bruni wrote: Right, the stable has a preconditio which limits it to pharo 1.2. Furthermore the initialization code seems to be incompatible as it uses to:do: on Character which is AFAIK not implemented in the core image Pharo 1.3. Hence apply the following changes: KMKeyEvent class initializeControlSequences ... $a asciiValue to: $z asciiValue do: [:each | d add: each asCharacter - (each - $a asciiValue + 1)]. ... then it should work. m(^_-)m camillo On 2011-03-03, at 09:25, Tudor Girba wrote: Hi, I am very interested to get Keymapping integrated into Glamour. Could someone help me to load it? I tried
Re: [Pharo-project] need your attention: Package
Hi Stef, Thanks a lot for all this effort. I will reiterate again the original idea, which I still believe would work best. RPackage is meant to become the organization entity in the image. MCPackage will still be needed for versioning. Furthermore, for a while, categories will still remain in the system for a while as an implementation detail. RPackages mirror each category. The first step would be to keep loading from Monticello exactly like it is now: it will create Categories, and this will mirror in RPackages. The next step is to provide a tool that provides only a 1-1 mapping between MC and RPackages that we can use for publishing. In this way, we would be able to: - load existing MC without problems - publish new MCPackages that will be compatible with other dialects Indeed, Metacello configurations will need modifications, but we have a smooth path to it. The Metacello configurations are still typically used only for loading and that will still continue to work just like they do now. With the Metacello Browser things will change, but then again we can change that tool, too. The only problem is how to define class extensions. I believe the * magic mapping is in MC. That will create problems, but for a while, I think we can still rely on this mapping. Cheers, Doru On 19 Mar 2011, at 22:20, Stéphane Ducasse wrote: On Mar 19, 2011, at 7:17 PM, Guillermo Polito wrote: BTW, for smooth transition, why not just replace usages of PackageInfo by RPackage keeping everything working as today? And after that, we can improve the way we use it. In two words, why not replace only infrastructure instead of infrastructure and behavior at the same time? Doing both together is kind of complex and easy to make mistakes... yes this is what cyrille started to do. On top of RPackage so may be cleaning that is the way to go. but the matching semantics is not good. But maybe it's easier (or nicer) to replace everything together... :P Guille On Sat, Mar 19, 2011 at 1:35 PM, Dale Henrichs dhenr...@vmware.com wrote: Stef, I would say that trying to diverge from category-based packaging for MC1 would pretty much be a disaster. the big problem is not what happens within Pharo (which is a tough enough problem to solve), but what happens to other folks (Squeak or GemStone or even VW in this case) trying to use mcz files created in Pharo that no longer align with the class and method categories? It will not be pretty. On the other hand, MC2 has been designed from the beginning to allow for alternate package definition schemes ... category-based packaging has always been a hack Perhaps this is time to start a push towards MC2 and perhaps RPackage-based packaging could become part of MC2 or at least one of the packaging schemes ... For transition, MC1 would continue to use category-based packages and those projects that wanted to preserve MC1 compatibility would simply continue to name the categories to make MC1 happy and use RPackage for MC2 packages with a different rule set ... One of the problems with MC2 has been the lack of a compelling reason to make the transition to a new system ... RPackage and the associated tools could be the compelling reason to move to MC2... Dale On Mar 18, 2011, at 1:56 PM, Stéphane Ducasse wrote: Hi guys we need to think about package: right now we have a new implementation that is fast, robust and supports well a new generation of tools (glamour, nautilus...). We are capturing all system events and we would be more or less ready to remove systemNotifier and use Announcement instead. RPackage can live also on the side of PackageInfo for a while but it would be better to have the shortest possible period of co-existence. Now one of the problem I see is that we may not have a smooth transition because: - Rpackage does not rely on category tagging matching. - It is simpler to have a mapping from current categories to packages - Now it means that we could load a package in the system and it would be turned into several RPackages so this means that configuration would have to be adapted. - marcus was suggesting me to create a package with the same contents as the one of loaded by MC. and to have tags to only represent categories. Now my time is short so I will - probably not implement tags - check again the implementation of RPackage and in particular the necessary compatibility layer, because I saw some strange code. - check the MC dependency on method category conventions, because some logic is not defined in the right place like overrides in the MC tools and not in the PackageInfo - check how a package gets created when loaded: the key question is that there is a problem to rely on categories to associate classes to packages because we can end up with overlapping (normally
Re: [Pharo-project] [ANN 1.2] prebuilt core 1.2 final
Hi Marcus, I completely agree. Now, just one thing. We have to start with putting in place a full fledged dev image as soon as a new Core version is started. Like this we can use that one from the beginning. For example, in Moose we switch to the new version as soon as the dev is available. Cheers, Doru On 18 Mar 2011, at 08:13, Marcus Denker wrote: Yes, but it was not done for 1.2 and 1.2 is *finished*. If we want to do that, we need to do that *not after the release is released* but before. This whole thing just shows that I only look at 1.2 when it is released *DOES NOT WORK*. 1.2 Core was Release Canditate for *two months*. Release Canditate means this will be released *unchanged* if no problems are found. So isn't *that* the point to do things that could need a fix in the release? I am really tempted to declare 1.3 stable now and abandon any concept of release, as it's a complete waste of time. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. -- www.tudorgirba.com Every thing should have the right to be different.
Re: [Pharo-project] need your attention: Package
On 20 Mar 2011, at 09:18, Stéphane Ducasse wrote: On Mar 19, 2011, at 10:55 PM, Tudor Girba wrote: Hi Stef, Thanks a lot for all this effort. I will reiterate again the original idea, which I still believe would work best. RPackage is meant to become the organization entity in the image. MCPackage will still be needed for versioning. Furthermore, for a while, categories will still remain in the system for a while as an implementation detail. RPackages mirror each category. The first step would be to keep loading from Monticello exactly like it is now: it will create Categories, and this will mirror in RPackages. this sentence is not clear doru. Do you mean that a RPackage should contain classes that are contained in matching PackageInfo package? I mean RFoo contains RFoo and RFoo-zork categories classes? No. I meant we have a 1-1 mapping to categories. So, you will get multiple RPackages in the system: RFoo, RFoo-zork ... The next step is to provide a tool that provides only a 1-1 mapping between MC and RPackages that we can use for publishing. The problem is not publishing the problem is assigning classes to packages. I think that if we split loading and publishing logic as a transition phase it would solve the problem, and I actually believe that you are talking about a similar thing (see below). In this way, we would be able to: - load existing MC without problems - publish new MCPackages that will be compatible with other dialects let us see imagine the following scenaro PI-Foo contains Foo Foo-Zork = We get RFoo and RFoo-Zork we can save and people can load now I add a category Foo-Two in pharo I get an extra package we should modify metacelloConfig ok people can load it too in other system it will be in Foo ok we can load it Now if we should preserve the current loading semantics **package creation** when PI-Foo contains Foo Foo-Zork if we should create only one RFoo containing all the FooCat then we arrive to the point where this is not clear that when I add a new cat it will not be in. The solution I proposed was a new publishing interface for MC that works with the 1-1 mapping between RPackage and PackageInfo. Like this, for saving we would be force to save the new package. So, in your case, when you would open the NewMC, you would see in the list: Foo Foo-Zork Foo-Cat* The +Package button would disappear altogether. You would be provided with the possible things to commit, and then you would not have to think about the mapping at all. All you have to do is select each of the RPackages that you want to commit, and if there does not exist a correspondent Monticello package for it, you would be asked to provide the repo and then the creation would happen transparently. So we could always load and create a RPackage for each Category. This would be simpler. In your solution, you would again split the mapping logic of load from that of publishing but you would change the loading mapping such that when you load you create only one category per PI. Perhaps that is indeed simpler, but you would lose the extra info of categories. Were my explanations clearer now? Cheers, Doru Indeed, Metacello configurations will need modifications, but we have a smooth path to it. The Metacello configurations are still typically used only for loading and that will still continue to work just like they do now. With the Metacello Browser things will change, but then again we can change that tool, too. The only problem is how to define class extensions. I believe the * magic mapping is in MC. That will create problems, but for a while, I think we can still rely on this mapping. yes Cheers, Doru On 19 Mar 2011, at 22:20, Stéphane Ducasse wrote: On Mar 19, 2011, at 7:17 PM, Guillermo Polito wrote: BTW, for smooth transition, why not just replace usages of PackageInfo by RPackage keeping everything working as today? And after that, we can improve the way we use it. In two words, why not replace only infrastructure instead of infrastructure and behavior at the same time? Doing both together is kind of complex and easy to make mistakes... yes this is what cyrille started to do. On top of RPackage so may be cleaning that is the way to go. but the matching semantics is not good. But maybe it's easier (or nicer) to replace everything together... :P Guille On Sat, Mar 19, 2011 at 1:35 PM, Dale Henrichs dhenr...@vmware.com wrote: Stef, I would say that trying to diverge from category-based packaging for MC1 would pretty much be a disaster. the big problem is not what happens within Pharo (which
Re: [Pharo-project] need your attention: Package
Hi Stef, I do not want to select the RPackage that maps to an MCPackage. This should be done transparently by the tool: 1 Category maps on 1 RPackage and this maps on a potential MCPackage. Let's take an example. You load the original MCPackage Foo: Foo Foo Foo-Bar We get 2 RPackages: Foo and Foo-Bar. We add a new RPackage Foo-Zoo. We open the NewMCInterface and we get three MCPackages: Foo Foo-Bar Foo-Zoo The Foo-Zoo MCPackage is offered without any explicit creation. Like this you take away the extra step and you control the mapping in the way you want. Cheers, Doru On 20 Mar 2011, at 10:04, Stéphane Ducasse wrote: Thanks doru. I will digest that. I have the impression that I understand your approach but would not it be error prone to select the Rpackages you want to map to MCPackage? Stef Hi Stef, Thanks a lot for all this effort. I will reiterate again the original idea, which I still believe would work best. RPackage is meant to become the organization entity in the image. MCPackage will still be needed for versioning. Furthermore, for a while, categories will still remain in the system for a while as an implementation detail. RPackages mirror each category. The first step would be to keep loading from Monticello exactly like it is now: it will create Categories, and this will mirror in RPackages. this sentence is not clear doru. Do you mean that a RPackage should contain classes that are contained in matching PackageInfo package? I mean RFoo contains RFoo and RFoo-zork categories classes? No. I meant we have a 1-1 mapping to categories. So, you will get multiple RPackages in the system: RFoo, RFoo-zork ... The next step is to provide a tool that provides only a 1-1 mapping between MC and RPackages that we can use for publishing. The problem is not publishing the problem is assigning classes to packages. I think that if we split loading and publishing logic as a transition phase it would solve the problem, and I actually believe that you are talking about a similar thing (see below). In this way, we would be able to: - load existing MC without problems - publish new MCPackages that will be compatible with other dialects let us see imagine the following scenaro PI-Foo contains Foo Foo-Zork = We get RFoo and RFoo-Zork we can save and people can load now I add a category Foo-Two in pharo I get an extra package we should modify metacelloConfig ok people can load it too in other system it will be in Foo ok we can load it Now if we should preserve the current loading semantics **package creation** when PI-Foo contains Foo Foo-Zork if we should create only one RFoo containing all the FooCat then we arrive to the point where this is not clear that when I add a new cat it will not be in. The solution I proposed was a new publishing interface for MC that works with the 1-1 mapping between RPackage and PackageInfo. Like this, for saving we would be force to save the new package. So, in your case, when you would open the NewMC, you would see in the list: Foo Foo-Zork Foo-Cat* The +Package button would disappear altogether. You would be provided with the possible things to commit, and then you would not have to think about the mapping at all. All you have to do is select each of the RPackages that you want to commit, and if there does not exist a correspondent Monticello package for it, you would be asked to provide the repo and then the creation would happen transparently. So we could always load and create a RPackage for each Category. This would be simpler. In your solution, you would again split the mapping logic of load from that of publishing but you would change the loading mapping such that when you load you create only one category per PI. Perhaps that is indeed simpler, but you would lose the extra info of categories. Were my explanations clearer now? Cheers, Doru Indeed, Metacello configurations will need modifications, but we have a smooth path to it. The Metacello configurations are still typically used only for loading and that will still continue to work just like they do now. With the Metacello Browser things will change, but then again we can change that tool, too. The only problem is how to define class extensions. I believe the * magic mapping is in MC. That will create problems, but for a while, I think we can still rely on this mapping. yes Cheers, Doru On 19 Mar 2011, at 22:20, Stéphane Ducasse wrote: On Mar 19, 2011, at 7:17 PM, Guillermo Polito wrote: BTW, for smooth transition, why not just replace usages of PackageInfo by RPackage keeping everything working
Re: [Pharo-project] [UPD] NativeBoost runs on new Cog VMs
Exciting :) Cheers, Doru On 20 Mar 2011, at 12:51, Igor Stasenko wrote: Hello, i just wanna to inform you that i adopted NativeBoost plugin for building with latest Cog vms. To build VM, you should have an image with VMMaker + CMakeVMMaker packages installed. Then load NBIntaller package and do: NBInstaller installCogPlugin There are new cmake configurations i added to build VMs with NB plugin support. So, simply do as usual: NB config name generateWithSources and then cmake. / make P.S. Im happy knowing that the OpenGL fonts rendering demo, which i made almost a year ago works out of the box on Windoze :) -- Best regards, Igor Stasenko AKA sig. -- www.tudorgirba.com There are no old things, there are only old ways of looking at them.
Re: [Pharo-project] [ANN] More on Keymappings
Excellent! I can't wait to use it when it's ready :) Doru On 20 Mar 2011, at 17:33, Camillo Bruni wrote: The keymapping framework is already close to be completely rewritten. Most tests work (except for 3). Half of the methods are gone and the event matching works directly on Event level, no more evil string matching. I'll ping as soon as the rest of the tests work properly. camillo On 2011-03-19, at 13:37, Mariano Martinez Peck wrote: Add keymappings to http://book.pharo-project.org/book/PharoTools/ I will add it as soon as the cleanup is complete and all tests work again :). -- www.tudorgirba.com Sometimes the best solution is not the best solution.
[Pharo-project] test crashing the cog vm
Hi, Alex recently wrote a test in Moose that seems to crash the Cog VM at least on Mac. How to reproduce: - download the following image http://dl.dropbox.com/u/18323746/Tmp/moose-crashing-cog-jit.zip - execute the following code in the workspace (already provided in the image) cls := Class new superclass: MooseElement; yourself. cls compileSilently: 'mooseName ^ 1/0'. element := cls new. - I used all of the followings and they all crashed: https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/Cog%20Mac%20Cocoa/4/artifact/cog/build/Cog.zip https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/StackVM%20Mac%20Cocoa/2/artifact/cog/build/StackVM.zip http://www.mirandabanda.org/files/Cog/VM/VM.r2370/Cog.app.tgz http://www.mirandabanda.org/files/Cog/VM/VM.r2361/Cog.app.tgz The strange thing is that the crash only happens when we subclass MooseElement, but not another class. Could someone take a look? Cheers, Doru -- www.tudorgirba.com Every thing should have the right to be different.
Re: [Pharo-project] test crashing the cog vm
Thanks, Toon! I changed the code to explicitly set the format, and it seems to fix the problem: cls := Class new superclass: MooseElement; setFormat: MooseElement format; yourself. cls compileSilently: 'mooseName ^ 1/0'. element := cls new. Is this correct? Cheers, Doru On 21 Mar 2011, at 10:57, Toon Verwaest wrote: This does crash whenever you subclass a class which has instance variables and you try to access those instance variables. The problem is that you don't properly initialize your class, leaving you with a Class that has a wrong format. For example: cls := Class new superclass: Class; yourself. cls format returns 2. 2 basically means it's an object with pointers but with 0 instance variables. If you instantiate the 'cls' I just made it also crashes. Why? Well, class has an initialize method that is compiled to write to the fields of the new instance. It puts an empty method dictionary into the class you create as an instance of my cls. This segfaults because you are writing outside of memory. So just make sure you properly create classes, with a proper format! This test should crash all VMs btw... at least at some point. Since you are writing in random memory it might take longer to notice it in some cases; especially when padded memory is owned by the garbage collector :) cheers, Toon On 03/21/2011 10:24 AM, Tudor Girba wrote: Hi, Alex recently wrote a test in Moose that seems to crash the Cog VM at least on Mac. How to reproduce: - download the following image http://dl.dropbox.com/u/18323746/Tmp/moose-crashing-cog-jit.zip - execute the following code in the workspace (already provided in the image) cls := Class new superclass: MooseElement; yourself. cls compileSilently: 'mooseName ^ 1/0'. element := cls new. - I used all of the followings and they all crashed: https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/Cog%20Mac%20Cocoa/4/artifact/cog/build/Cog.zip https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/StackVM%20Mac%20Cocoa/2/artifact/cog/build/StackVM.zip http://www.mirandabanda.org/files/Cog/VM/VM.r2370/Cog.app.tgz http://www.mirandabanda.org/files/Cog/VM/VM.r2361/Cog.app.tgz The strange thing is that the crash only happens when we subclass MooseElement, but not another class. Could someone take a look? Cheers, Doru -- www.tudorgirba.com Every thing should have the right to be different. -- www.tudorgirba.com Every thing has its own flow.
Re: [Pharo-project] A step toward reducing complexity
Thanks, Doug. This was on my to do list for a long time. Just a note: GLMUITheme is part of Glamour. Please do not fork it in Pharo and integrate fixes there because then it will just get messy. I will integrate it in Glamour. If you want to evolve it in the context of Pharo, you should rename it an put it in a different package (this would probably make sense anyway). Cheers, Doru On 25 Mar 2011, at 08:44, Stéphane Ducasse wrote: Thanks. May be the windowActiveDropShadowStyle could be just added to the UITheme class? Open a bug entry and attach code or slice there so that - have a look - not forget to integrate the fix. Stef Reduce the complexity of user interface themes In general, user interface themes should inherit directly from UITheme, not from a chain of themes. When you have a chain of themes, you are stuck with the intermediate themes, whether you need/use them or not. Consider GLMUITheme. Currently it is under UIThemeWatery2, which is under UIThemeWatery, which is under UITheme. Some characteristics inherited from the chain are missing, but in principal, GLMUITheme can be moved directly under UITheme with just 3 changes. 1. Add an instanceVariable 'windowActiveDropShadowStyle' UITheme subclass: #GLMUITheme instanceVariableNames: 'windowActiveDropShadowStyle' classVariableNames: '' poolDictionaries: '' category: 'Glamour-Morphic-Theme' 2. Add a class method isAbstract Answer whether the receiver is considered to be abstract. ^false 3. Add an instance method windowActiveDropShadowStyle: anObject Set the value of windowActiveDropShadowStyle windowActiveDropShadowStyle := anObject Because GLMOrangeUITheme inherits these changes, it does not need modification. -- View this message in context: http://forum.world.st/A-step-toward-reducing-complexity-tp3404504p3404504.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. -- www.tudorgirba.com We are all great at making mistakes.
Re: [Pharo-project] Pharo 1.2 red again
Sounds great. So, what needs to be done then? I would be interested to use this in the context of Moose as well. Cheers, Doru On 24 Mar 2011, at 21:36, Stéphane Ducasse wrote: this is a good news Stef On Mar 24, 2011, at 4:59 PM, Dale Henrichs wrote: Stef, Yep ... all the pieces are there ... it's just a matter of putting them together in the right order..this is what we do for GemStone GLASS builds... Dale On Mar 24, 2011, at 1:21 AM, Stéphane Ducasse wrote: henrichs do you know if you have now the pieces in place to be able to freeze a configuration and all its recursive sets in a dedicated repository? Stef -- www.tudorgirba.com Every successful trip needs a suitable vehicle.
Re: [Pharo-project] who is using softSqueak and standard Squeak
Hi, I vote to not keep them in the distribution. Perhaps there are a handful of people that use them, but this should be solvable by making the themes loadable. Cheers, Doru On 27 Mar 2011, at 09:39, Stéphane Ducasse wrote: We could get a new colored one because if it helps people this can be good. Now I was jus wondering if we stay with these two endlessly. Stef On Mar 26, 2011, at 1:57 PM, Lukas Renggli wrote: Yeah, I kind of liked the colored windows, but nowadays I got used to the mac look. Lukas On 26 March 2011 09:40, Stéphane Ducasse stephane.duca...@inria.fr wrote: Hi guys just out of curiosity who is using SoftSqueak and Standard Squeak theme? I know that lukas like colored windows now may be specific new style with this behavior could be done? Stef -- Lukas Renggli www.lukas-renggli.ch -- www.tudorgirba.com The coherence of a trip is given by the clearness of the goal.
[Pharo-project] squeaksource is down
squeaksource.com is down. Cheers, Doru -- www.tudorgirba.com Relationships are of two kinds: those we choose and those that happen. They both matter.
