- Pharo-users - lists.pharo.org

Re: [Pharo-users] [Pharo-project] in anybody out there? who uses 2.0?

by stephane ducasse

we should plit that in bug entries and take actions collectively :) On Mar 28, 2013, at 4:56 AM, Yanni Chiu <yanni(a)rogers.com> wrote: > On 27/03/13 10:24 AM, Esteban Lorenzano wrote: >> >> Here in Pharo headquarters we are shock that there are just 10 new bugs reported for 2.0 after the release... >> So... I wonder... is that because we made a really cool release, or just because nobody is using it? > > Just before the release I loaded up my project, and did a quick check to find that everything looked fine - except that I would have to migrate to Fuel-1.9. > > I had noticed that package loading seemed extremely slow, but did not look further into it. I think I saw mention that it's due to some usage of #become:, during the compiling of code. Based on build times (of just loading the rough equivalent code), it seems about 3 times slower to do a build on a Pharo-2.0 vs. Pharo-1.4. > > The slowness is not just an annoyance, because I actually compile code in my application - it's just compiling getters and setters. I've not got enough working yet to see whether it's going to adversely affect the usability (it could make startup time too slow). > > Another thing I've noticed is occasional sluggishness in the UI. It's hard to pinpoint, I often feel like my clicks are being lost. > > The behaviour of the TestRunner was odd. Eventually I discovered running tests via the Nautilus browser, but the UI feedback is extremely confusing for "abstract" test cases. I still don't quite understand the results I see there, so I do a final run of the tests in the TestRunner. > > Another strange issue I had with test cases was to do with the interaction of the deprecation warnings. In by build script, I run: > Deprecation raiseWarning: false. > Deprecation showWarning: false. > so the build can run headless. It took me a few hours, and a careful single stepping, to find that the deprecation exceptions were being swallowed. I'm sure the TestRunner did not behave this way before. If you ran a test, you would still see the deprecation exceptions. It was really frustrating to see your test fail, but have the stack cleared out before you could debug the exception that caused the test failure. > > Are these bugs, or just me getting used to the new release? > >

March 28, 2013

Re: [Pharo-users] in anybody out there? who uses 2.0?

by Goubier Thierry

Le 27/03/2013 15:24, Esteban Lorenzano a Ã©crit : > Hi, > > Here in Pharo headquarters we are shock that there are just 10 new bugs reported for 2.0 after the release... > So... I wonder... is that because we made a really cool release, or just because nobody is using it? > > Cheers, > Esteban Hi, I've started to load things in 2.0 (SmaCC, some of my current work) but then the current work caught me back and I'm finishing it on 1.4 at the moment. Oh, I think I also stopped because I couldn't load FileTree in 2.0 and I need it for a git-based workflow. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

March 28, 2013

Re: [Pharo-users] [Pharo-project] in anybody out there? who uses 2.0?

by Marcus Denker

On Mar 28, 2013, at 4:56 AM, Yanni Chiu <yanni(a)rogers.com> wrote: > > > I had noticed that package loading seemed extremely slow, but did not look further into it. I think I saw mention that it's due to some usage of #become:, during the compiling of code. Based on build times (of just loading the rough equivalent code), it seems about 3 times slower to do a build on a Pharo-2.0 vs. Pharo-1.4. > Yes, this is known and we should analyze itâ¦ one thing we need to get rid of os the #become: when updating the source pointer. There seems to be something slow with announcing changes, too. > > Another thing I've noticed is occasional sluggishness in the UI. It's hard to pinpoint, I often feel like my clicks are being lost. > I have not seen that one. > The behaviour of the TestRunner was odd. Eventually I discovered running tests via the Nautilus browser, but the UI feedback is extremely confusing for "abstract" test cases. I still don't quite understand the results I see there, so I do a final run of the tests in the TestRunner. > Odd in which sense? related to the progress bar? > Another strange issue I had with test cases was to do with the interaction of the deprecation warnings. In by build script, I run: > Deprecation raiseWarning: false. > Deprecation showWarning: false. > so the build can run headless. It took me a few hours, and a careful single stepping, to find that the deprecation exceptions were being swallowed. I'm sure the TestRunner did not behave this way before. If you ran a test, you would still see the deprecation exceptions. It was really frustrating to see your test fail, but have the stack cleared out before you could debug the exception that caused the test failure. > Can you add a bug tracker entry for that one? Marcus

March 28, 2013

Re: [Pharo-users] in anybody out there? who uses 2.0?

by smalltalk

which os do you use? 2013/3/28 Yanni Chiu <yanni(a)rogers.com> > On 27/03/13 10:24 AM, Esteban Lorenzano wrote: > >> >> Here in Pharo headquarters we are shock that there are just 10 new bugs >> reported for 2.0 after the release... >> So... I wonder... is that because we made a really cool release, or just >> because nobody is using it? >> > > Just before the release I loaded up my project, and did a quick check to > find that everything looked fine - except that I would have to migrate to > Fuel-1.9. > > I had noticed that package loading seemed extremely slow, but did not look > further into it. I think I saw mention that it's due to some usage of > #become:, during the compiling of code. Based on build times (of just > loading the rough equivalent code), it seems about 3 times slower to do a > build on a Pharo-2.0 vs. Pharo-1.4. > > The slowness is not just an annoyance, because I actually compile code in > my application - it's just compiling getters and setters. I've not got > enough working yet to see whether it's going to adversely affect the > usability (it could make startup time too slow). > > Another thing I've noticed is occasional sluggishness in the UI. It's hard > to pinpoint, I often feel like my clicks are being lost. > > The behaviour of the TestRunner was odd. Eventually I discovered running > tests via the Nautilus browser, but the UI feedback is extremely confusing > for "abstract" test cases. I still don't quite understand the results I see > there, so I do a final run of the tests in the TestRunner. > > Another strange issue I had with test cases was to do with the interaction > of the deprecation warnings. In by build script, I run: > Deprecation raiseWarning: false. > Deprecation showWarning: false. > so the build can run headless. It took me a few hours, and a careful > single stepping, to find that the deprecation exceptions were being > swallowed. I'm sure the TestRunner did not behave this way before. If you > ran a test, you would still see the deprecation exceptions. It was really > frustrating to see your test fail, but have the stack cleared out before > you could debug the exception that caused the test failure. > > Are these bugs, or just me getting used to the new release? > > >

March 28, 2013

Re: [Pharo-users] in anybody out there? who uses 2.0?

by Yanni Chiu

On 27/03/13 10:24 AM, Esteban Lorenzano wrote: > > Here in Pharo headquarters we are shock that there are just 10 new bugs reported for 2.0 after the release... > So... I wonder... is that because we made a really cool release, or just because nobody is using it? Just before the release I loaded up my project, and did a quick check to find that everything looked fine - except that I would have to migrate to Fuel-1.9. I had noticed that package loading seemed extremely slow, but did not look further into it. I think I saw mention that it's due to some usage of #become:, during the compiling of code. Based on build times (of just loading the rough equivalent code), it seems about 3 times slower to do a build on a Pharo-2.0 vs. Pharo-1.4. The slowness is not just an annoyance, because I actually compile code in my application - it's just compiling getters and setters. I've not got enough working yet to see whether it's going to adversely affect the usability (it could make startup time too slow). Another thing I've noticed is occasional sluggishness in the UI. It's hard to pinpoint, I often feel like my clicks are being lost. The behaviour of the TestRunner was odd. Eventually I discovered running tests via the Nautilus browser, but the UI feedback is extremely confusing for "abstract" test cases. I still don't quite understand the results I see there, so I do a final run of the tests in the TestRunner. Another strange issue I had with test cases was to do with the interaction of the deprecation warnings. In by build script, I run: Deprecation raiseWarning: false. Deprecation showWarning: false. so the build can run headless. It took me a few hours, and a careful single stepping, to find that the deprecation exceptions were being swallowed. I'm sure the TestRunner did not behave this way before. If you ran a test, you would still see the deprecation exceptions. It was really frustrating to see your test fail, but have the stack cleared out before you could debug the exception that caused the test failure. Are these bugs, or just me getting used to the new release?

March 28, 2013

Re: [Pharo-users] in anybody out there? who uses 2.0?

by Victor Stan

O tried it, it works pretty well overall, just a bit sluggish in the UI side of things, also some issued with editing code and then moving between characters and words in code, sometimes the cursor just to unexpected places, like the beginning of the file, for some reason... going to try to keep an eye on it and see if I can come up with a more reproducible description. Thanks for all the hard work, as I said, in general pretty solid. Victor Stan Schedule me: http://quicklyschedule.quicklyschedule.me/victor Add me to your address book - it's easy! http://contactmonkey.com/victor On Wed, Mar 27, 2013 at 3:54 PM, Chris <cpmbailey(a)btinternet.com> wrote: > I normally wait a few weeks after a release before having a bit of a look > myself. I did try loading Seaside in it and it complained about > OmniBrowser, and then tried Gitocello and that didn't load either. I guess > it's only natural that people take some time to update their projects to a > new version but given how key Seaside is to Pharo, I think that needs to > work out of the box (I'm sure it does with the right version to be fair but > was just pretending to be a newbie and using the configuration browser) > > Nautilus is going to be a bit of a learning curve for me as well. My > automatic typing into that top box on 1.4 is going to take some overcoming! > > > Hi, >> >> Here in Pharo headquarters we are shock that there are just 10 new bugs >> reported for 2.0 after the release... >> So... I wonder... is that because we made a really cool release, or just >> because nobody is using it? >> >> Cheers, >> Esteban >> >> >> > > >

March 27, 2013

Re: [Pharo-users] More GSoC ideas wanted, 3 days left ....

by Norbert Hartl

Wow! That is something I just researched a few days before and think it would be really helpful for distributed stuff Just want to say Norbert Am 27.03.2013 um 17:39 schrieb Paul DeBruicker <pdebruic(a)gmail.com>: > This is the second of two not well fleshed out ideas. > > On 03/26/2013 04:36 AM, Janko MivÅ¡ek wrote: >> Title: > Implement Fast Byzantine Paxos in Slang > > >> Level: (beginner, intermediate, advanced) > > Advanced > >> Possible mentor: (if already known) >> >> Possible second mentor: (if already known) > > I am willing to help out but I'm sure there's someone better as I don't > know slang or how to go about implementing Paxos. yet. > >> Description > Paxos (https://en.wikipedia.org/wiki/Paxos_%28computer_science%29) is a > framework for solving consensus in a network of unreliable processors. > A python implementation is available here: http://openreplica.org/ > >> Technical Details > Could just port ConCoord (the openreplica.org's backend) from Python to > Slang rather than starting from scratch. > >> Benefits to the Student > Learn Smalltalk, Slang. Implement something hard. > >> Benefits to the Community > With enough images you can just persist everything in the image and each > image can be a reasonable size. >

March 27, 2013

Re: [Pharo-users] More GSoC ideas wanted, 3 days left ....

by Paul DeBruicker

On 03/27/2013 10:30 AM, Janko MivÅ¡ek wrote: > Hi Paul, > > Can you continue describing your idea so that one will grasp the > essentials without needing to open first the Wikipedia links. Idea looks > promising, just not clarified yet enough. I'm pretty user you can > continue evolving it by yourself. > > Best regards > Janko > Sure I'll give it a shot, but caveat emptor: > Dne 27. 03. 2013 17:39, piÅ¡e Paul DeBruicker: >> This is the second of two not well fleshed out ideas. >> >> On 03/26/2013 04:36 AM, Janko MivÅ¡ek wrote: >>> Title: >>> >> Implement Fast Byzantine Paxos in Slang >> >> Paxos is a system for ensuring consensus across a network of processors (e.g. multiple images on multiple computers or cpus on the same hardware). Fast Byzantine Paxos is Paxos extended to ensure reliability in the face of arbitrary failures among processors, lying from processors, collusion among more than once lying processor, etc. Fast Byzantine Paxos is just a version of Byzantine Paxos that omits a step seemingly trading network latency for additional CPU work. But I'm not sure of the tradeoffs. >>> Level: (beginner, intermediate, advanced) >>> >> >> Advanced >> >>> Possible mentor: (if already known) >>> >>> Possible second mentor: (if already known) >>> >> >> I am willing to help out but I'm sure there's someone better as I don't >> know slang or how to go about implementing Paxos. yet. >> >>> Description >>> >> Paxos (https://en.wikipedia.org/wiki/Paxos_%28computer_science%29) is a >> framework for solving consensus in a network of unreliable processors. >> A python implementation is available here: http://openreplica.org/ >> My basic understanding is that among a set of images (technically "processors" but I'm going to use image because it seems more relevant here) you construct a quorum. That quorum calculates and agrees on a response to a client request. The quorum survives and is the unit of computation but the individual images inside it change in make up and number through time as images and machines die and come back. The quorum maintains and replicates the state among its member images. The images in the quorum can at any time assume at least one of 5 roles (client, acceptor, proposer, learner, leader) for that quorum and most play all but leader all the time. The images can participate in more than one quorum. There is only one 'leader' per quorum (but the leader can be any image in the quorum and is 'elected' by the quorum members) and sends messages to others in the quorum to process. I'm not sure of the gory details but the client sends a request to the quorum, the quorum processes it, and sends back the one agreed upon response regardless of how many machines are in the quorum that fail or fail to respond during the computation. Paxos describes all the intra process communication that needs to take place to ensure that the quorum provides reliable responses to requests in the face of hardware and network failures. Implementing it in Slang would potentially make it faster than in image (guessing) because C and it could be a plugin. >>> Technical Details >>> >> Could just port ConCoord (the openreplica.org's backend) from Python to >> Slang rather than starting from scratch. >> It is my understanding that implementing Paxos from scratch and covering all corner cases and failure modes is very very hard. Probably also confusing. Sorry I don't know more but here's a zip of the papers I've collected that describe ways and issues around implementing it: http://dl.dropbox.com/u/4460862/paxos-papers.zip >>> Benefits to the Student >>> >> Learn Smalltalk, Slang. Implement something hard. >> Also build a robust distributed Smalltalk system. >>> Benefits to the Community >> With enough images you can just persist everything in the image and each >> image can be a reasonable size. >> >> > Other benefits include making a (hardware, network) failure resistant server Smalltalk process

March 27, 2013

Re: [Pharo-users] in anybody out there? who uses 2.0?

by Chris

I normally wait a few weeks after a release before having a bit of a look myself. I did try loading Seaside in it and it complained about OmniBrowser, and then tried Gitocello and that didn't load either. I guess it's only natural that people take some time to update their projects to a new version but given how key Seaside is to Pharo, I think that needs to work out of the box (I'm sure it does with the right version to be fair but was just pretending to be a newbie and using the configuration browser) Nautilus is going to be a bit of a learning curve for me as well. My automatic typing into that top box on 1.4 is going to take some overcoming! > Hi, > > Here in Pharo headquarters we are shock that there are just 10 new bugs reported for 2.0 after the release... > So... I wonder... is that because we made a really cool release, or just because nobody is using it? > > Cheers, > Esteban > > >

March 27, 2013

Re: [Pharo-users] More GSoC ideas wanted, 3 days left ....

by Juan Pablo Sandoval Alcocer

2013/3/26 Janko MivÅ¡ek <janko.mivsek(a)eranova.si> > > To propose an idea just respond to this post by fulfilling this idea > template: > > * Gadget (the inspector) Level: Intermediate Possible mentor: Juan Pablo Sandoval Alcocer Possible second mentor: Alexandre Bergel Description: Understanding how an application behaves at runtime requires adequate tools. However, MessageTally, the standard Smalltalk code profiler, is very limited in the kind of analyzis it can carry out. Spy (a profiler framework) is an attempt that has been made in the past, however Spy suffers from poor design, typically forcing profilers to contain a heavy dose of duplicate code. In this project, we plan to produce Gadget, a portable, open and flexible profiling platform. Hapao [1], Kai [2] and Rizel [3] will be migrated from Spy to Gadget. Gadget will not only provide features to measure code coverage, time consumption, snapshot comparison, but will provide tools to monitor memory consumption. All these features will provide to Pharo developers the tools to create domain specific profilers and reuse the features of different implemented profilers in Gadget. Technical Details: In this project the student will: - define and implement a profiler metamodel. - learn and implement instrumentation and/or sampling techniques. - migrate three profilers from Spy to Gadget. Benefits to the Student: The student will (i) address performance problems; maintainability, design and evolution issues. (ii) get a better understanding of the executing environment of Pharo; (iii) learn reflection and dynamic analysis basics. Benefits to the Community: - Have a new open-source profiler framework with a smooth implementation of the feedback and experience from the community. * * - Allow the community to develop new profilers on top of Gadget which are easier to implement and maintain. *

March 27, 2013