June 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] light-table: live programming for python

by Marcus Denker

On Jun 1, 2012, at 5:03 PM, Esteban A. Maringolo wrote: > We're not missing much, and somehow Smalltalk and particularly Pharo provides > much more. > > It's funny how a non-mainstream lang like Clojure was able to pitch a tool > like this to raise $300K in Kickstarter. I envy these kind of outcomes, and > always makes me thing what we, Smalltalkers as a community, are missing > something regarding communication/marketing. Yes. Marcus -- Marcus Denker -- http://marcusdenker.de

June 1, 2012

[Pharo-project] [update 2.0] #20103

by Esteban Lorenzano

20103 ----- Issue 6006: mac vm tests get stucked on mac http://code.google.com/p/pharo/issues/detail?id=6006 Issue 6003: Missing Class Comment for FreetypeFontProvider http://code.google.com/p/pharo/issues/detail?id=6003 Issue 6001: Deprecated ReferenceStream http://code.google.com/p/pharo/issues/detail?id=6001

June 1, 2012

Re: [Pharo-project] What i would like to have instead of progress bar

by Chris Cunningham

On Thu, May 31, 2012 at 4:58 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > If you would ask me (yeah nobody asking me, by i will tell anyways ;) ) > how the indication of a progress of some process should look like, > here's my potential answer: <snip> > - no stupid nesting.. i don't care what happens inside of something > else happens.. > if it is really necessary, i would just replace the title of a task > with it's subtask title while it performing. > this is just about first rule: it has to be a single line, not a bunch > of lines stocking one over another.. > i think this is abuse. > > most of the times, i just need a notion of progress of a whole thing, > not progress of it's subthings I have cases where I have multiple background processes going on that occassionally wake up, and in that case, I really, really appreciate the stacking progress bars - I can tell that one (or more) background processes have kicked off. This isn't quite 'nesting', although I think it uses some of the same features. As long as some result out of this discussion doesn't remove that capability, I agree with what you are saying. -Chris

June 1, 2012

Re: [Pharo-project] light-table: live programming for python

by Esteban A. Maringolo

We're not missing much, and somehow Smalltalk and particularly Pharo provides much more. It's funny how a non-mainstream lang like Clojure was able to pitch a tool like this to raise $300K in Kickstarter. I envy these kind of outcomes, and always makes me thing what we, Smalltalkers as a community, are missing something regarding communication/marketing. Best regards, -- Esteban -- View this message in context: http://forum.world.st/light-table-live-programming-for-python-tp4632751p463… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 1, 2012

[Pharo-project] [update 1.4] #14444

by Esteban Lorenzano

14444 ----- Issue 5966: DropListMorph do not pop the list when the text field is clicked http://code.google.com/p/pharo/issues/detail?id=5966 Issue 5627: "MessageNotUnderstood: receiver of "displayWorld" is nil" on clicking the red Menu-Halo. http://code.google.com/p/pharo/issues/detail?id=5627

June 1, 2012

[Pharo-project] [URGENT] ESUG Conference in Gent: Student volunteers and call for presentations

by Damien Cassou

Less than 10 slots left for the ESUG student volunteer program. Apply now! http://www.esug.org/Conferences/2012/StudentVolunteers Only 2 weeks left to propose your presentation for ESUG http://www.esug.org/Conferences/2012/Call-for-Presentations -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

June 1, 2012

Re: [Pharo-project] about cursor: an interesting blog post

by Frank Shearar

On 1 June 2012 13:38, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>>> usly mentioned)) that are the abomination. >>>> >>> in smalltalk code & data is the same - it just objects. >>> why you think "changing your brain" should stop you from doing something else? >>> When you coding in browser, you alsos changing systems brain. >> >> Yes, there is no difference between loading a package and entering the >> same code through the browser... except that in the former case >> (without the abominatory modal progress dialogs stopping your) you >> might ALSO be adding code, or be running something, or or or. >> >> So you start loading some package. That package sadly has a bug in its >> replacement of Object >> #printString which accidentally kills the >> image. You're busy debugging something while that package loads. >> You're inspecting something. You inspect it again... and your image >> dies! You know you weren't doing anything crazy, so this time it's not >> your fault. But was it a VM bug? Some weird edge case in the base >> image noone's run into before? Monticello? The package being loaded? > > that can even happen without monticello being blocking... > >> While that package is loading - while you are busy hacking away - the >> image is changing under your feet. That is _never_ safe. Now, in happy >> land, we'd have sandboxes and isolation and atomic loading and all >> sorts of fun stuff so, in happy land, this wouldn't be a problem. But >> _today_ it would be a problem. > > sure it could be, but let's say we make a setting. Cause most of the time > I know exactly what I load in Monticello and still wan to be able to work > on something else. > > It's like having a #become: around, nobody stops you from doing silly > things with it :). At least with #become: you have to actually type out the letters: you KNOW you're doing something dangerous. > - Most of the UI stuff should be written non-blocking, adding blocking support > Â on top is mostly easy. (in MC the only thing that makes sense to be run > Â in blocking mode is indeed loading, but even that necessarily) I should perhaps restate that I _agree_ with Igor that I don't think the UI should ever block (except maybe at shutdown, but the user doesn't care at that point anyway). I just wanted to highlight that changing the system while a large amount of changing the system is already happening is asking for trouble. > - add Options/Settings (maybe with some warnings) so everybody is happy Well, too many settings = nobody happy, because noone's system works the same as anyone else's! frank

June 1, 2012

Re: [Pharo-project] light-table: live programming for python

by Frank Shearar

On 1 June 2012 13:29, Camillo Bruni <camillobruni(a)gmail.com> wrote: > impressive how much support they got: > > http://www.kickstarter.com/projects/ibdknox/light-table > > not much missing in our system, is it? No, definitely not. Most of it is automatically pulling up contextual info (like if you're implementing #myFoo on some object, bring up all the implementors in some no-clicks-needed window (possibly with some classes preferentially highlighted - sub/superclasses and other classes that satisfy similar protocols) and the senders of same in another (with suitable highlighting of the actual send site). The more clever de-abstraction stuff we can get quite easily by manipulating ASTs. (In a Smalltalk-based system, I'd half expect us to keep ASTs attached to method on which the programmer worked.) frank

June 1, 2012

Re: [Pharo-project] about cursor: an interesting blog post

by Camillo Bruni

>>> usly mentioned)) that are the abomination. >>> >> in smalltalk code & data is the same - it just objects. >> why you think "changing your brain" should stop you from doing something else? >> When you coding in browser, you alsos changing systems brain. > > Yes, there is no difference between loading a package and entering the > same code through the browser... except that in the former case > (without the abominatory modal progress dialogs stopping your) you > might ALSO be adding code, or be running something, or or or. > > So you start loading some package. That package sadly has a bug in its > replacement of Object >> #printString which accidentally kills the > image. You're busy debugging something while that package loads. > You're inspecting something. You inspect it again... and your image > dies! You know you weren't doing anything crazy, so this time it's not > your fault. But was it a VM bug? Some weird edge case in the base > image noone's run into before? Monticello? The package being loaded? that can even happen without monticello being blocking... > While that package is loading - while you are busy hacking away - the > image is changing under your feet. That is _never_ safe. Now, in happy > land, we'd have sandboxes and isolation and atomic loading and all > sorts of fun stuff so, in happy land, this wouldn't be a problem. But > _today_ it would be a problem. sure it could be, but let's say we make a setting. Cause most of the time I know exactly what I load in Monticello and still wan to be able to work on something else. It's like having a #become: around, nobody stops you from doing silly things with it :). - Most of the UI stuff should be written non-blocking, adding blocking support on top is mostly easy. (in MC the only thing that makes sense to be run in blocking mode is indeed loading, but even that necessarily) - add Options/Settings (maybe with some warnings) so everybody is happy

June 1, 2012

[Pharo-project] light-table: live programming for python

by Camillo Bruni

impressive how much support they got: http://www.kickstarter.com/projects/ibdknox/light-table not much missing in our system, is it?

June 1, 2012