- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] enclosing compile errors & <PrintIt> in double quotes

by Tudor Girba

Exactly. There is no need anymore to have an "in-text" printed error. A non-modal popup (similar to a menu) would be a better solution. We should treat the result of print-it in the same way and offer it non-invasively. I put together a visual description of how such a widget would look like here: https://dl.dropboxusercontent.com/u/18323746/Tmp/coder/coder-pop-print.pdf Would anyone be interested to work on this widget? Doru On Sat, Oct 19, 2013 at 12:14 AM, Benjamin < benjamin.vanryseghem.pharo(a)gmail.com> wrote: > Why not a small popup placed correctly ? > > Then it doesn't even corrupt your source code > > Ben > > On Oct 18, 2013, at 4:08 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > That is the first step :), if you have a decent text editor, > > you could add a real print-it or do-it token, which is not regarged as > source code, but just > as meta information. I think we could quite easily do this in Amber right > now ;). > > But yes, why not, sounds like a reasonable idea to put print-its and > compilation errors in double quotes. > > > On 2013-10-18, at 14:59, btc(a)openinworld.com wrote: > > > Just a random idea flitting thought my mind... When trying to <Accept> > some code with an error in it, the error message gets inserted into the > code such that it screws up syntax highlighting and also you need to use > <Undo> to remove it. I wonder if the error might be inserted between > double-quotes making it a comment. The same could be said for if you > <PrintIt> from a debugger. It seems such a simple and obvious idea that I > presume its been considered before and there are good reasons not to do it. > I am curious what others think might be the pros/cons of it. > In the case of <PrintIt> one benefit might be that the code could still be > saved, with the result left as a kind-of example. This might be good for > temporary code development in a Workspace. > > cheers -ben > > > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 19, 2013

Re: [Pharo-dev] enclosing compile errors & <PrintIt> in double quotes

by Benjamin

Why not a small popup placed correctly ? Then it doesn't even corrupt your source code Ben On Oct 18, 2013, at 4:08 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > That is the first step :), if you have a decent text editor, > > you could add a real print-it or do-it token, which is not regarged as source code, but just > as meta information. I think we could quite easily do this in Amber right now ;). > > But yes, why not, sounds like a reasonable idea to put print-its and compilation errors in double quotes. > > > On 2013-10-18, at 14:59, btc(a)openinworld.com wrote: > >> >> Just a random idea flitting thought my mind... When trying to <Accept> some code with an error in it, the error message gets inserted into the code such that it screws up syntax highlighting and also you need to use <Undo> to remove it. I wonder if the error might be inserted between double-quotes making it a comment. The same could be said for if you <PrintIt> from a debugger. It seems such a simple and obvious idea that I presume its been considered before and there are good reasons not to do it. I am curious what others think might be the pros/cons of it. >> In the case of <PrintIt> one benefit might be that the code could still be saved, with the result left as a kind-of example. This might be good for temporary code development in a Workspace. >> >> cheers -ben >> >

Oct. 18, 2013

Commit rights to Pharo30Inbox

by Attila Magyar

Hi list, I want to submit a SLICE to the pharo inbox, can you grant me commit rights? username: zeroflag thanks!

Oct. 18, 2013

Re: [Pharo-dev] recovering from a deep disc crashâ¦.

by Nicolas Cellier

beautiful link 2013/10/18 Torsten Bergmann <astares(a)gmx.de> > Hardware that runs without problems must be from the "good old days". > > If Nico is right then I guess Pharo is already running on an "Ural-1"? > Where can I download the VM? > > http://en.wikipedia.org/wiki/Ural_(computer) > > I try to imagine the size of the apartment and the way it was stolen... ;) > > Thats why Native Boost is so fast on newer machines, it was handcraftet > on an old machine to speed it up... :) > > Bye > T. > > > Nico wrote: > >Igor, > >your hardware never failed? > >It must be some special brand crafted in former soviet union ;) > > > >2013/10/18 Igor Stasenko <siguctua at gmail.com> > > > >> thankfully, i never had problems with hardware: it serves me well. > >> But still didn't prevented from losing precious data: the humans who > break > >> into my apartment and stole the machine, > >> with all data it has :( > >

Oct. 18, 2013

Re: [Pharo-dev] [Vm-dev] Mac VM Maintainer resignation (for the general purpose VM, not for PharoVM)

by David T. Lewis

Esteban, Thank you very much for your contributions, and thank you also for clarifying your position. I know there is much more that you will be contributing to our community at large and I appreciate what you have done so far. Dave > > Hi, > > This is an announce for VM-dev and Squeak-dev list, Pharo-dev list is copy > to keep people informed. > > Last years I tried to keep a working version of the Mac builds of VM while > at the same time trying to keep my job going. It was a hard work but I did > my best. > When I assumed the responsibility I said that my first task was going to > be to automatize the builds and at the same time Igor was doing the same > so I joined that effort. Since then the VM is buildable even by the not so > good at VM level and I never seen the point in keeping the manual build or > the non-smalltalk-generated configuration files. > Nevertheless, I preferred to work on the new builds of Eliot than in the > old interpreter and when keeping all working became more work that what I > could manage, I choose to keep Stack and Cog VM working. > > Maybe because of that, or because the animosity between communities, or > because what I'm doing just does not match Squeak vision, or because since > Eliot is providing regular builds mine are not needed, truth is that I've > seen my work mostly ignored in squeak community and for some of the people > in vm-dev list. > > That's why I resign as a maintainer. I have a process that does not match > squeak vision and is fair for squeak community to look for someone who > does. > > I have no bad feelings, I'm complete grateful to the community for give me > the opportunity (specially to John, who thrusted me) and to all the rest. > > I also know that there is great people both in vm-dev and in squeak-dev, > but I cannot your mac-guy anymore (and I think this is obvious since > ever). > > And of course I will continue working in the pharo flavor of VM :) > > Cheers, > Esteban

Oct. 18, 2013

Character>>#leadingChar

by Sven Van Caekenberghe

Hi, So once again we have an issue with Character>>#leadingChar, see https://pharo.fogbugz.com/f/cases/6368 Do we really need this ? Any Japanese, Chinese or Korean users willing to comment ? Thx, Sven

Oct. 18, 2013

new validation reports

by Camillo Bruni

1.5 h train delay resulted in a productive personal mini sprint :P, the monkey reports now a twitter bootstrap styled page with lots of useful information: https://ci.inria.fr/pharo/job/Pharo-3.0-Issue-Validator/905//artifact/valid… now I will see how it behaves with the most common validation problems :)

Oct. 18, 2013

Re: [Pharo-dev] Second Scheduler migration from SqS to STHub

by HernÃ¡n Morales Durand

Hi Torsten, Yes, I didn't see it because I was searching by class name. Now I have removed the second copy from the repository. Thanks for the advice, HernÃ¡n 2013/10/18 Torsten Bergmann <astares(a)gmx.de> > Hi Hernan, > > I've seen that you now registered "TaskScheduler" on STHub with the > Scheduler code on STHub. > > But the "Scheduler" project was already migrated to SmalltalkHub, together > with a config > and documented STHub page: > > http://smalltalkhub.com/#!/~TorstenBergmann/Scheduler > > and it is available also in the config browser for Pharo 2.0 since a long > time. No need for duplicated effort... > > Is there a reason you provide it a second time? May I kindly ask that you > remove your > second copy to avoid confusion. > > Thanks > Torsten >

Oct. 18, 2013

Anyone else teaching programming in Pharo?

by J.F. Rick

I've been teaching introductory programming in Pharo for the last three semesters and starting my fourth. I was wondering whether anyone else is doing that. I've put quite a bit of effort into it and would be willing to share my materials if anyone was interested. For instance, I've created a few little MicroWorlds for beginners to use (jumping directly into the browser is too difficult for complete programming novices). One is for doing turtle graphics. I've gone ahead and shared that for Pharo 2.0. You can get it in the Configuration Browser under the name EduTech. If you have some interest, let me know and I'll see what I can do. Cheers, Jeff -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

Oct. 18, 2013

Re: [Pharo-dev] Generators implemented only with blocks

by Francisco Garau

On 18 Oct 2013, at 08:55, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 18.10.2013 um 09:35 schrieb Francisco Garau <francisco.garau(a)gmail.com>: > >> Hi - >> >> On 18 Oct 2013, at 06:54, Norbert Hartl <norbert(a)hartl.name> wrote: >> >>> Why not just >>> >>> gen := [ | current | >>> current := 0. >>> [ current := current + 1 ] ] value. >>> >> >> Much concise indeed. But I am trying to have several generators instantiated from the same block definition and be able to set their initial values to any number. Just for fun, of course. >> > genGen := [ : initial | | current | > current := initial. > [ current := current + 1 ] ]. > > gen := genGen value: 10. > gen2 := genGen value: 50. > > (1 to: 10) inject: OrderedCollection new into: [ :col :elem | > col add: gen value. > col add: gen2 value. > col ] Very nice! I also wanted to reset their values at any time. That's why I had to return blocks to initialise and provide the next value. > Norbert > >>> >>> I think there is two sides of using blocks. One is the ability to carry some code around which is a useful thing. The other one is that encloses over the current environement. The latter is something that you can use for quite powerful stuff. But it is also something people have problems to understand and that can easily introduce problems in code because you didn't think of what it does. >>> Just remember the last problem with announcements that was caused by blocks. So blocks are to me like a lot of other programming techniques: If you don't really need them don't use them. >>> >>> Norbert >>> >>> Am 18.10.2013 um 00:46 schrieb Francisco Garau <francisco.garau(a)gmail.com>: >>> >>>> Hi >>>> >>>> As an exercise, I've implemented a simple Generator using only blocks: >>>> >>>> gen := >>>> [ >>>> [ | currentValue | >>>> Array >>>> with: [ currentValue := 0 ] >>>> with: [ currentValue := currentValue + 1 ] >>>> ] value >>>> ] value. >>>> >>>> gen first value. >>>> next := [:a | a last value]. >>>> >>>> getTen := [(1 to: 10) collect: [ :i | next value: gen ]]. >>>> >>>> getTen value = #(1 2 3 4 5 6 7 8 9 10). >>>> getTen value = #(11 12 13 14 15 16 17 18 19 20). >>>> >>>> >>>> There have been some funny arguments in the past whether Blocks are a fundamental part of Smalltalk or not. My code above supports Vassili's view that we could get rid of Objects and implement everything in terms of Blocks. >>>> >>>> http://live.exept.de/doc/online/english/programming/humor.html >>>> >>>> But more seriously, I find it quite interesting that Lars Bak choose not to implement Blocks for his Resilient Smalltalk. He choose to implement LIFO blocks; that is, blocks that cannot survive the creating activation context (see chapter 2.3 for more details). >>>> >>>> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.84.7354&rep=rep1&t… >>>> >>>> - Francisco >>>> >>> >

Oct. 18, 2013