October 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Comment Syntax

by Lukas Renggli

The problem is that both #/* and #/* are valid binary operators, so they don't work well for comments. I don't really remember what I proposed a few years ago, although I remember that exactly the same proposal was made. What would work is to use something like "* and *" (or any other double thing that starts with a double quote). Like this the comments could contain double quotes. As a short term solution you can also put your comments into single quotes. Unused string literals are removed by the compiler. Lukas On 31 October 2011 22:00, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Me too. > > Sean lukas proposed a syntax for that in the mailing-list a year ago. > If you find it please resent it. > > Stef > > On Oct 31, 2011, at 9:12 PM, Sean P. DeNigris wrote: > >> Would it be difficult/valuable to create an alternate comment syntax? I often >> find myself wanting to comment a large block itself containing comments. It >> would be nice to have something like C++'s /* */. I feel like this may have >> been brought up before, but couldn't find it searching the lists. >> >> Sean >> >> -- >> View this message in context: http://forum.world.st/Comment-Syntax-tp3961451p3961451.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > > > -- Lukas Renggli www.lukas-renggli.ch

Oct. 31, 2011

Re: [Pharo-project] The rubber progress bar is stretching too fast

by StÃ©phane Ducasse

+ 1 just no time/energy/ to fix it Stef On Oct 31, 2011, at 9:51 PM, Nicolas Cellier wrote: > Do you really like this new progress bar that resizes at high frequency? > It's funny 5 minutes, but hardly any longer... > > Shouldn't we restrict update frequency to some number? maybe 2Hz or a > bit more... > Higher frequencies are not readable, and 2Hz is enough to show that > progress occurs. > > Could we reduce downsizing frequency too? > Between 0 and 0.5 Hz would be well enough to my taste. > > Any better idea? > > Nicolas >

Oct. 31, 2011

Re: [Pharo-project] The rubber progress bar is stretching too fast

by Mariano Martinez Peck

yes, it looks too fast for me...I would rather something slower as it was before... On Mon, Oct 31, 2011 at 9:51 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > Do you really like this new progress bar that resizes at high frequency? > It's funny 5 minutes, but hardly any longer... > > Shouldn't we restrict update frequency to some number? maybe 2Hz or a > bit more... > Higher frequencies are not readable, and 2Hz is enough to show that > progress occurs. > > Could we reduce downsizing frequency too? > Between 0 and 0.5 Hz would be well enough to my taste. > > Any better idea? > > Nicolas > > -- Mariano http://marianopeck.wordpress.com

Oct. 31, 2011

Re: [Pharo-project] Comment Syntax

by StÃ©phane Ducasse

Me too. Sean lukas proposed a syntax for that in the mailing-list a year ago. If you find it please resent it. Stef On Oct 31, 2011, at 9:12 PM, Sean P. DeNigris wrote: > Would it be difficult/valuable to create an alternate comment syntax? I often > find myself wanting to comment a large block itself containing comments. It > would be nice to have something like C++'s /* */. I feel like this may have > been brought up before, but couldn't find it searching the lists. > > Sean > > -- > View this message in context: http://forum.world.st/Comment-Syntax-tp3961451p3961451.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Oct. 31, 2011

Re: [Pharo-project] Brainstorming on the roadmap for first Pharo Consortium Engineer :)

by StÃ©phane Ducasse

When igor release athens, we will really ask him to get a 100% fully working FFI will be the most important task Stef On Oct 31, 2011, at 8:04 PM, Schwab,Wilhelm K wrote: > The object-c bridge is probably a big deal to the Mac users among us, right? My understand is that there are quite a few of you?? I've thought about it myself, but that's another story. > > For external interfacing, I would very much like to see callbacks widely supported; I'm thinking of solvers/minimizers etc., where one needs to tell the library how to evaluate a function. FFI has been pretty good to me, and Andreas described something that might be turned into a reusable callback mechanism for it. Alien and NativeBoost are also options. It would be nice if we had one external interface system that does it all. > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Noury Bouraqadi [bouraqadi(a)gmail.com] > Sent: Monday, October 31, 2011 11:17 AM > To: Pharo-project(a)lists.gforge.inria.fr > Cc: A friendly place where any question about pharo is welcome > Subject: Re: [Pharo-project] Brainstorming on the roadmap for first Pharo Consortium Engineer :) > > What about adding to this todo list: > > -Fixing/finishing the Objective-C bridge :-) > During ESUG 2010 Esteban told me that there was a pb with the Mac VM that causes the crash. > I believe this wasn't fixed and this is the biggest issue with the MARS project. > > Noury > On 31 oct. 2011, at 11:54, StÃ©phane Ducasse wrote: > >> Hi guys >> >> we have a roadmap for Esteban and we would like to share it with you. We have extra items that we would like to see fixed and we are welcoming your >> feedback/suggestions. Note this is typically the way we want to work with the consortium in the future: >> Build an initial roadmap and refine it based on the input of the community. >> >> - A website for the consortium registration (esteban is expert on that). >> - This is important for INRIA and for the visibility of the consortium. We should get new members :) >> - Integration with SmalltalkHub >> >> - Working on fixing bugs! >> - Debugger fixes >> - Continuous bug fixing. >> >> - Improving release process: faster, more people involved, simpler. >> - Working on metacello repositories for each distributions (everything is there but missing last bits) >> - Metacello tools >> - Automatic release validations >> - Automatic validation of fixes >> >> Now the free items with probably igor involvement >> - Multiwindowing support >> - Fully working multithreaded FFI with ***Documentation*** >> - Filesystem fix and integration >> - Integration of OPAL >> - RPackage integration >> >> Igor related >> - Ephemerons >> - Object format >> - VM branding >> - Use of new canvas >> - Event cleaning >> >> So we are waiting for your suggestions. >> >> >> Stef >> >> >> >> > > Noury > -- > http://twitter.com/#!/NouryBouraqadi > > > > > > >

Oct. 31, 2011

Re: [Pharo-project] Brainstorming on the roadmap for first Pharo Consortium Engineer :)

by Mariano Martinez Peck

- Once again... I would LOVE to have a really working-out-of-the-box multithreaded FFI with callbacks. This is a MUST if Pharo wants to be business friendly. - Unify the VMs. Have only ONE place where a single pharo user can go and pickup a VM. Have ANOTHER place for those bleeding edge or experiment VMs. This means merging gforge, jenkins, pharo website, pharo one click, etc. In addition, we need a way to IDENTIFY a VM. So that when someone reports a bug, we can exactly know which VM to reproduce it. - Integrate Nautilus with RB. Nobody (ok, most of us) cannot work without RB integration. Ok, integrations could live without that, but they INTEGRATE. If you are DEVELOPING you cannot develop without RB. If nobody will make OB to work in 1.4, then someone needs to integrate Nautilus with RB, otherwise people will stick with 1.3 and never change. - Make development really tools work in Pharo 1.4: OCompletion, Shout - Continue pushing Coral, Zinc, Ocean, DBXTalk, Fuel, Nautilus, etc. - Maintain issue tracker: let's give Marcus a rest. This means tagging issues, close them, validate, etc etc etc. Cheers On Mon, Oct 31, 2011 at 8:25 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > I can't take credit for thinking of the bridge, I was simply acknowledging > it and the breadth of its audience as part of my shameless attempt to > direct effort toward another feature that would get a lot of use :) > > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Sean P. > DeNigris [sean(a)clipperadams.com] > Sent: Monday, October 31, 2011 3:22 PM > To: pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Brainstorming on the roadmap for first Pharo > Consortium Engineer :) > > Schwab,Wilhelm K wrote: > > > > The object-c bridge is probably a big deal to the Mac users among us, > > right? > > Yes! Thank you for the reminder, I'd temporarily given up and forgotten > about this. A stable, well-documented ObjC bridge would be /huge/. My > inability to effectively use it was one of the key drivers in my delving > into debugging the VM. Like FFI, I think documentation will be extremely > important here. > > Sean > > -- > View this message in context: > http://forum.world.st/Brainstorming-on-the-roadmap-for-first-Pharo-Consorti… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > -- Mariano http://marianopeck.wordpress.com

Oct. 31, 2011

Re: [Pharo-project] Is FS loadable in 1.3?

by StÃ©phane Ducasse

Yes it should. Stef On Oct 31, 2011, at 9:26 PM, Sean P. DeNigris wrote: > Thanks. > Sean > > -- > View this message in context: http://forum.world.st/Is-FS-loadable-in-1-3-tp3961499p3961499.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Oct. 31, 2011

Re: [Pharo-project] Athens news :)

by StÃ©phane Ducasse

Igor let wild people have a look. Provide a script so that people can load and a bunch of examples. Stef On Oct 31, 2011, at 5:21 PM, Igor Stasenko wrote: > The text rendering is most complex part. And it going very slow, > slower than i thought. > Apart from text, there's a lot things to think about. > But what i want to do right now is to implement enough functionality > to fully render morphic desktop in pharo. > And then we can discuss what else we need as well as what we dont need :) > > > > -- > Best regards, > Igor Stasenko. >

Oct. 31, 2011

Re: [Pharo-project] Athens news :)

by StÃ©phane Ducasse

For now just watching and reading it. Since this is pre pre pre pre release. Stef On Oct 31, 2011, at 3:43 PM, Tudor Girba wrote: > Great. I can't wait to play with it :) > > Doru > > > On Mon, Oct 31, 2011 at 11:06 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > I asked igor to do a pre pre pre pre release of athens and then perform regular ones so that you can follow what he is doing > and get excited. Because this is getting along and will open a lot of perspective. > > The idea is that igor is working since september on Athens: a new canvas and a smalltalk backend to support it. > The challenge are: > - how can we get a zoomable vector graphics system? with for examples back end in Cairo/opengl. > - what are the good abstractions to support that? > > Igor is then working on a "simple" text model and canvas so that we can emit instructions for vector graphics > back-ends. > > Stef > > > > > > -- > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Oct. 31, 2011

Re: [Pharo-project] DateAndTime vs TimeStamp

by StÃ©phane Ducasse

I would like to merge the two. In fact there was an horrible hack that a string would compare equally to the timestamp based on DNU and other dark magic. Now I guess that having a good printing policy object would make the merging easier. Stef > Hi, > > I am used to using TimeStamp as my default 'point-in-time' class, although it differs only very slightly from DateAndTime. This was not really a very explicit decision, it just sounded/felt right. Now that I am having some timezone issue to sort out, the way DataAndTime's are printed is more helpful. > > So the question is: why do we have these two, very similar, classes ? Do we need them ? > > I vaguely remember there is a Seaside directive: do not just TimeStamp (maybe only for portability) ? > > In short, what is the rationale behind this situation ? > > Thx, > > Sven > > > >

Oct. 31, 2011