March 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Fwd: Squeak 5 on Raspberry Pi

by HernÃ¡n Morales Durand

2016-03-25 19:32 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Stef, > > On Fri, Mar 25, 2016 at 2:27 PM, stepharo <stepharo(a)free.fr> wrote: > >> So guys, you do not want Xtreams (and prefer to use Streams that have >> been "designed" decades ago) ;D ? >> no bootstrapped core (clement you do not want to have a mini image :) ? >> and a new UI frameworks? >> > > yes, of course :-) > > >> I personnally want to have new widgets, a real UI builder and massively >> cleaning Spec. >> Now I would like to have multiple tool sets - I understand that people >> like the new debugger (I do not like it) - >> I want the possibility to have a mini tools tool set. >> > > +1 > > >> If you want to clean Pharo you can start cleaning Komitter stupid use of >> state pattern generating >> a lot of garbage instead of having a single animated morph. >> >> We should clean Versionner- I have the impression that half of the >> classes are not mandatory. >> > > I don't think this is either or. I don't think Hilaire is saying "don't > do feature-rich releases". I think Hilaire is saying "do separate > feature-rich and consolidation releases". > > I think Hilaire is making a good suggestion of having some releases being > for new functionality and some for consolidation. So perhaps the community > could schedule a Pharo N, followed by a Pharo N.1, or schedule a Pharo M, > where M is even (or odd) and a Pharo N, where N is odd (or even), and have > the N.1, or N is odd (or even) releases being consolidation releases as > Hilaire describes, with no new features and only bug fixes and performance > improvements. If the community can manage it, it could do one new feature, > followed by one consolidation release a year. But if so, the community > needs to be serious about the consolidation releases and put real effort > into them. > > The advantage for the broader user base is clear; there is a steady stream > of releases that more conservative users can use, that exhibits good > stability and better performance than the bleeding edge. > > Also, there's no reason why these release cycles can't overlap. The only > time they must not overlap is when the community needs to focus on the new > release. So for example, for two months of the year, six months apart, the > community should focus on the new release, be it consolidation or > feature-rich, and make sure we release promptly and correctly. But the > other ten months of the year there's no reason why the community cannot > work on either release. This requires infrastructure such as two > repositories, one for each, such as pharo-features and pharo-stable, and > the discipline to separate one's work correctly, but it could be a really > good thing. I'm sure others can think this through better than I. What do > others suggest? > In my opinion, that sounds like a very good and more serious approach for the whole community. The only problem I see is an explosion of Pharo flavors like happened in Squeak years ago, because many people want promotion of their own image (which is ok but also reflects lack of consensus), but is better than having new core projects with developers abandoning before time or obscure decisions imposing a new debugger without ANY poll. Now I don't want to waste time on definitions of "solid", but I can tell you Pharo now feels slow. About having to ask "spend some time optimising tools" just a few weeks before a release... Sorry guys I know you work a lot on making good quality stuff, but seems like the current way of integrating tools **is NOT working**. Where is the policy for integrating packages and tools into the core? Where are the priorities? Why they are priorities? How many votes gets each? Want more contributors? Start with clean visible rules and listen to users. We all want UFFI, Xtreams, mini-image, new UI frameworks & builder, etc. but not at any cost. HernÃ¡n

March 26, 2016

Re: [Pharo-dev] [squeak-dev] Re: [Vm-dev] I would be extremely grateful for a reproducible case for the following Socket issue

by Eliot Miranda

Hi Levente, the first thing to report is that this isn't a Cog-specific bug. It also reproduces using the trunk VM sources (4.15.3) and a freshly built linux VM with a 4.6 image. On Thu, Mar 24, 2016 at 2:16 AM, Levente Uzonyi <leves(a)caesar.elte.hu> wrote: > Hi Eliot, > > The snippet below, evaluated from a workspace, triggered the issue in less > than a minute for me, three times in a row. > Both processes will halt if #sloppyWaitForDataIfClosed: doesn't return > within a second. If you send #dataAvailable to the socket, you'll find that > it has data ready to be read, but its readSemaphore has no signal. > > Levente > > > Socket compile: 'sloppyWaitForDataIfClosed: closedBlock > > [(socketHandle ~~ nil > and: [self primSocketReceiveDataAvailable: socketHandle]) ifTrue: > [^self]. > self isConnected ifFalse: > [^closedBlock value]. > self readSemaphore wait] repeat' > classified: 'waiting'. > > [ > listenerSocket := Socket newTCP. > listenerSocket listenOn: 0 backlogSize: 4 interface: #[127 0 0 1]. > clientSocket := Socket newTCP. > clientSocket connectTo: #[127 0 0 1] port: listenerSocket > localPort. > clientSocket waitForConnectionFor: 1. > self assert: clientSocket isConnected. > serverSocket := listenerSocket waitForAcceptFor: 1. > self assert: serverSocket isConnected ] > ensure: [ listenerSocket destroy ]. > > serverProcess := [ > | shouldRun buffer bytesReceived waitDuration | > shouldRun := true. > buffer := ByteString new: 10. > waitDuration := 1 second. > [ > [ serverSocket sloppyWaitForDataIfClosed: [ shouldRun := > false ] ] > valueWithin: waitDuration > onTimeout: [ self halt ]. > buffer atAllPut: (Character value: 0). > bytesReceived := serverSocket receiveDataInto: buffer. > self assert: bytesReceived = 4. > self assert: (buffer first: 4) = 'PING'. > serverSocket sendData: 'PONG' ] repeat ] newProcess. > clientProcess := [ > | shouldRun buffer bytesReceived waitDuration | > shouldRun := true. > buffer := ByteString new: 10. > waitDuration := 1 second. > [ > clientSocket sendData: 'PING'. > [ clientSocket sloppyWaitForDataIfClosed: [ shouldRun := > false ] ] > valueWithin: waitDuration > onTimeout: [ self halt ]. > buffer atAllPut: (Character value: 0). > bytesReceived := clientSocket receiveDataInto: buffer. > self assert: bytesReceived = 4. > self assert: (buffer first: 4) = 'PONG' ] repeat ] > newProcess. > clientProcess priority: 39; resume. > serverProcess priority: 39; resume. > > "Evaluate these after debugging: > clientSocket destroy. > serverSocket destroy." > > > > On Wed, 23 Mar 2016, Eliot Miranda wrote: > > Hi Levente, >> On Wed, Mar 23, 2016 at 11:31 AM, Levente Uzonyi <leves(a)caesar.elte.hu> >> wrote: >> Hi Eliot, >> >> What sort of reproducibility are you looking for? Is it enough if >> it happens once every few hours or do you need something that you can >> trigger on demand? >> >> >> I'll take every few hours, but I'd prefer "in under 30 minutes". Getting >> warm and fuzzy feelings when trying to prove a negative with something that >> takes hours to run is very difficult. Let's say you have >> a case which reproduces in 8 hours 50% of the time. To reach 99% >> confidence level in a fix I'd have to run it for 8 * (50 log: 2) hours >> without seeing it reproduce, right? That's nearly 2 days; it could >> take weeks to fix :-( >> >> Levente >> >> >> >> _,,,^..^,,,_ >> best, Eliot >> >> > > > -- _,,,^..^,,,_ best, Eliot

March 26, 2016

Re: [Pharo-dev] Fwd: Squeak 5 on Raspberry Pi

by Eliot Miranda

Hi Stef, On Fri, Mar 25, 2016 at 2:27 PM, stepharo <stepharo(a)free.fr> wrote: > So guys, you do not want Xtreams (and prefer to use Streams that have been > "designed" decades ago) ;D ? > no bootstrapped core (clement you do not want to have a mini image :) ? > and a new UI frameworks? > yes, of course :-) > I personnally want to have new widgets, a real UI builder and massively > cleaning Spec. > Now I would like to have multiple tool sets - I understand that people > like the new debugger (I do not like it) - > I want the possibility to have a mini tools tool set. > +1 > If you want to clean Pharo you can start cleaning Komitter stupid use of > state pattern generating > a lot of garbage instead of having a single animated morph. > > We should clean Versionner- I have the impression that half of the classes > are not mandatory. > I don't think this is either or. I don't think Hilaire is saying "don't do feature-rich releases". I think Hilaire is saying "do separate feature-rich and consolidation releases". I think Hilaire is making a good suggestion of having some releases being for new functionality and some for consolidation. So perhaps the community could schedule a Pharo N, followed by a Pharo N.1, or schedule a Pharo M, where M is even (or odd) and a Pharo N, where N is odd (or even), and have the N.1, or N is odd (or even) releases being consolidation releases as Hilaire describes, with no new features and only bug fixes and performance improvements. If the community can manage it, it could do one new feature, followed by one consolidation release a year. But if so, the community needs to be serious about the consolidation releases and put real effort into them. The advantage for the broader user base is clear; there is a steady stream of releases that more conservative users can use, that exhibits good stability and better performance than the bleeding edge. Also, there's no reason why these release cycles can't overlap. The only time they must not overlap is when the community needs to focus on the new release. So for example, for two months of the year, six months apart, the community should focus on the new release, be it consolidation or feature-rich, and make sure we release promptly and correctly. But the other ten months of the year there's no reason why the community cannot work on either release. This requires infrastructure such as two repositories, one for each, such as pharo-features and pharo-stable, and the discipline to separate one's work correctly, but it could be a really good thing. I'm sure others can think this through better than I. What do others suggest? Stef > > 2016-03-25 18:18 GMT+01:00 Hilaire <hilaire(a)drgeo.eu>: > >> Not exactly related to Announcement, but I remember when I first port >> DrGeo to Squeak (at that time Pharo did not exist) I used a lot of >> change/update when objects in the canvas changed. It was terribly slow, >> and later opted for a top-down update in the list of object. >> >> So some sometime what look like a cool stuff (decoupled objects) is just >> a drag. >> >> Regarding optimizing, I share my opinion here months ago, I think Pharo >> need consolidation releases: no new features, only bugs fix and speed >> improvement. There are enough new features in Pharo for a couple of >> years, but the product need to *be* solid and *feel* solid. >> > > +1 > > >> >> Hilaire >> >> Le 25/03/2016 12:33, Stephan Eggermont a Ã©crit : >> > On 25-03-16 11:49, Nicolai Hess wrote: >> >> Morphic drasticallly slower ? I would expect morphic code is mostly >> >> the same in pharo and squeak. If pharo is slower, this is a good >> >> starting point for optimising. Can you gives some hints? >> > I do not have the impression that morphic is so much slower. >> > We had/have a problem of too many announcements being send and >> > too many redraws happening. >> > >> > Stephan >> > >> > >> >> -- >> Dr. Geo >> http://drgeo.eu >> >> >> > > -- _,,,^..^,,,_ best, Eliot

March 25, 2016

Re: [Pharo-dev] Fwd: Squeak 5 on Raspberry Pi

by Nicolai Hess

2016-03-25 22:27 GMT+01:00 stepharo <stepharo(a)free.fr>: > So guys, you do not want Xtreams (and prefer to use Streams that have been > "designed" decades ago) ;D ? > no bootstrapped core (clement you do not want to have a mini image :) ? > and a new UI frameworks? > I want a clean and stable core. The way Rubric and GT-Tools were pushed into the core was a mess. Rubric is a big bad bunch of badly documented code with lots of copy-paste garbage - we should do better. And since it was included I hear it was abandoned by alain and TxText is the next. I see up to no development for TxText. The same for Athens, bugs or requests for conclusins I entered in FogBugz are, or will be closed (timout) because no one cares. Instead Athens is used as it is or change by others just for its own projects (roassal, Bloc, Brick). > > I personnally want to have new widgets, a real UI builder and massively > cleaning Spec. > me too, but what is the purpose of spec, if we replace all tools based on spec (debugger/inspector/...) with GT-Tools? > Now I would like to have multiple tool sets - I understand that people > like the new debugger (I do not like it) - > I want the possibility to have a mini tools tool set. > > If you want to clean Pharo > I fix bugs, there are many bugs. > you can start cleaning Komitter stupid use of state pattern generating > a lot of garbage instead of having a single animated morph. > > We should clean Versionner- I have the impression that half of the classes > are not mandatory. > > Our tools are in a much more worse state than in Pharo 4, not clean, not stable. We are in code freeze since 6 weeks, and there are still many new changes instead of only bug fixes. > Stef > > > > > 2016-03-25 18:18 GMT+01:00 Hilaire <hilaire(a)drgeo.eu>: > >> Not exactly related to Announcement, but I remember when I first port >> DrGeo to Squeak (at that time Pharo did not exist) I used a lot of >> change/update when objects in the canvas changed. It was terribly slow, >> and later opted for a top-down update in the list of object. >> >> So some sometime what look like a cool stuff (decoupled objects) is just >> a drag. >> >> Regarding optimizing, I share my opinion here months ago, I think Pharo >> need consolidation releases: no new features, only bugs fix and speed >> improvement. There are enough new features in Pharo for a couple of >> years, but the product need to *be* solid and *feel* solid. >> > > +1 > > >> >> Hilaire >> >> Le 25/03/2016 12:33, Stephan Eggermont a Ã©crit : >> > On 25-03-16 11:49, Nicolai Hess wrote: >> >> Morphic drasticallly slower ? I would expect morphic code is mostly >> >> the same in pharo and squeak. If pharo is slower, this is a good >> >> starting point for optimising. Can you gives some hints? >> > I do not have the impression that morphic is so much slower. >> > We had/have a problem of too many announcements being send and >> > too many redraws happening. >> > >> > Stephan >> > >> > >> >> -- >> Dr. Geo >> http://drgeo.eu >> >> >> > >

March 25, 2016

Re: [Pharo-dev] [squeak-dev] Green builds on Github

by Fabio Niephaus

That's great news! And thanks! Please feel free to get in touch if you run into any issues with Travis CI again. Best, Fabio -- On Fri, Mar 25, 2016 at 5:51 PM Max Leske <maxleske(a)gmail.com> wrote: > Hi, > > Just wanted to let you know that the Github builds are now all green > (since now the DateAndTime issue in Squeak has been fixed), i.e. > > Pharo-alpha, Pharo 5.0, Pharo 4.0, > Squeak-trunk, Squeak-4.6, Squeak-4.5 > > on both OS X and Linux. > > > See for yourself here: https://github.com/theseion/Fuel. > > Note that the sources are still being hosted on Smalltalkhub. Iâm > triggering the builds through the TravisCI API when I run a build on the > INRIA CI. > > > Iâd like to thank Tobias Pape and Fabio Niephaus for their help in setting > this up and for creating the SmalltalkCI infrastructure for TravisCI. > > Cheers, > Max >

March 25, 2016

Re: [Pharo-dev] Fwd: Squeak 5 on Raspberry Pi

by stepharo

But pharo is solid. When is the last time we changed FFI and GC and new object representations? You see FFI is really really important not having one = no Pharo. So yes Pharo is doing too much stuff and we should have sprint to clean and optimise but FFI and Spur are important. Stef Le 25/3/16 20:37, philippe.back(a)highoctane.be a Ã©crit : > > yes! > > Maybe a solid core with a layer of fast evolving things. > > That's the model for Hortonworks now. A stable Hadoop core for > stability and fast updates for things like Spark. > > Phil > > On Mar 25, 2016 6:19 PM, "Hilaire" <hilaire(a)drgeo.eu > <mailto:hilaire@drgeo.eu>> wrote: > > Not exactly related to Announcement, but I remember when I first port > DrGeo to Squeak (at that time Pharo did not exist) I used a lot of > change/update when objects in the canvas changed. It was terribly > slow, > and later opted for a top-down update in the list of object. > > So some sometime what look like a cool stuff (decoupled objects) > is just > a drag. > > Regarding optimizing, I share my opinion here months ago, I think > Pharo > need consolidation releases: no new features, only bugs fix and speed > improvement. There are enough new features in Pharo for a couple of > years, but the product need to *be* solid and *feel* solid. > > Hilaire > > Le 25/03/2016 12:33, Stephan Eggermont a Ã©crit : > > On 25-03-16 11:49, Nicolai Hess wrote: > >> Morphic drasticallly slower ? I would expect morphic code is mostly > >> the same in pharo and squeak. If pharo is slower, this is a good > >> starting point for optimising. Can you gives some hints? > > I do not have the impression that morphic is so much slower. > > We had/have a problem of too many announcements being send and > > too many redraws happening. > > > > Stephan > > > > > > -- > Dr. Geo > http://drgeo.eu > >

March 25, 2016

Re: [Pharo-dev] Fwd: Squeak 5 on Raspberry Pi

by stepharo

So guys, you do not want Xtreams (and prefer to use Streams that have been "designed" decades ago) ;D ? no bootstrapped core (clement you do not want to have a mini image :) ? and a new UI frameworks? I personnally want to have new widgets, a real UI builder and massively cleaning Spec. Now I would like to have multiple tool sets - I understand that people like the new debugger (I do not like it) - I want the possibility to have a mini tools tool set. If you want to clean Pharo you can start cleaning Komitter stupid use of state pattern generating a lot of garbage instead of having a single animated morph. We should clean Versionner- I have the impression that half of the classes are not mandatory. Stef > > > 2016-03-25 18:18 GMT+01:00 Hilaire <hilaire(a)drgeo.eu > <mailto:hilaire@drgeo.eu>>: > > Not exactly related to Announcement, but I remember when I first port > DrGeo to Squeak (at that time Pharo did not exist) I used a lot of > change/update when objects in the canvas changed. It was terribly > slow, > and later opted for a top-down update in the list of object. > > So some sometime what look like a cool stuff (decoupled objects) > is just > a drag. > > Regarding optimizing, I share my opinion here months ago, I think > Pharo > need consolidation releases: no new features, only bugs fix and speed > improvement. There are enough new features in Pharo for a couple of > years, but the product need to *be* solid and *feel* solid. > > > +1 > > > Hilaire > > Le 25/03/2016 12:33, Stephan Eggermont a Ã©crit : > > On 25-03-16 11:49, Nicolai Hess wrote: > >> Morphic drasticallly slower ? I would expect morphic code is mostly > >> the same in pharo and squeak. If pharo is slower, this is a good > >> starting point for optimising. Can you gives some hints? > > I do not have the impression that morphic is so much slower. > > We had/have a problem of too many announcements being send and > > too many redraws happening. > > > > Stephan > > > > > > -- > Dr. Geo > http://drgeo.eu > > >

March 25, 2016

Re: [Pharo-dev] fullscreen on MacOS (possible VM bug)

by stepharo

Lucky you :) I can crash randomly the system just changing the size of the display and not when we are loading code :) Le 25/3/16 20:49, J.F. Rick a Ã©crit : > In good news, this problem seems to not exist with the latest Pharo5 > VM + image (seems not backwards compatible to the Pharo4 image), so > that'll fix my problem as I'll just use Pharo5 instead of Pharo4 for > this project. > > Cheers, > > Jeff > > On Fri, Mar 25, 2016 at 1:08 PM J.F. Rick <self(a)je77.com > <mailto:self@je77.com>> wrote: > > In further details, when it is green-button maximized, then I can > run "Display fullscreenOn" and it doesn't crash. I also upgraded > the desktop to the latest OS (10.11.4) but that doesn't fix it. > > Cheers, > > Jeff > > On Fri, Mar 25, 2016 at 11:12 AM J.F. Rick <self(a)je77.com > <mailto:self@je77.com>> wrote: > > Hi, > > I'm trying to run fullscreen Pharo on MacOS using "Display > fullscreenOn". On my laptop (13" Macbook Pro, OS 10.11.4), > that works. On my desktop (MacMini, 4k display, OS 10.11.3), > the screen goes to black for several seconds and the VM > crashes. I am attaching the crash.dmp file. Note that this is > a new Pharo4.0 I just downloaded from pharo.org > <http://pharo.org>. > > If I maximize the screen using the green button on the Pharo > window, it does not crash. But, it does mean that anytime I > move my cursor towards the top the Apple menus appear. That's > not ideal for this purpose but could be acceptable. When I > quit and restart Pharo, it doesn't come back in full screen > mode. Is there Pharo code I can run to have it be in this kind > of fullscreen mode without user action? > > Cheers, > > Jeff >

March 25, 2016

Re: [Pharo-dev] fullscreen on MacOS (possible VM bug)

by J.F. Rick

In good news, this problem seems to not exist with the latest Pharo5 VM + image (seems not backwards compatible to the Pharo4 image), so that'll fix my problem as I'll just use Pharo5 instead of Pharo4 for this project. Cheers, Jeff On Fri, Mar 25, 2016 at 1:08 PM J.F. Rick <self(a)je77.com> wrote: > In further details, when it is green-button maximized, then I can run > "Display fullscreenOn" and it doesn't crash. I also upgraded the desktop to > the latest OS (10.11.4) but that doesn't fix it. > > Cheers, > > Jeff > > On Fri, Mar 25, 2016 at 11:12 AM J.F. Rick <self(a)je77.com> wrote: > >> Hi, >> >> I'm trying to run fullscreen Pharo on MacOS using "Display fullscreenOn". >> On my laptop (13" Macbook Pro, OS 10.11.4), that works. On my desktop >> (MacMini, 4k display, OS 10.11.3), the screen goes to black for several >> seconds and the VM crashes. I am attaching the crash.dmp file. Note that >> this is a new Pharo4.0 I just downloaded from pharo.org. >> >> If I maximize the screen using the green button on the Pharo window, it >> does not crash. But, it does mean that anytime I move my cursor towards the >> top the Apple menus appear. That's not ideal for this purpose but could be >> acceptable. When I quit and restart Pharo, it doesn't come back in full >> screen mode. Is there Pharo code I can run to have it be in this kind of >> fullscreen mode without user action? >> >> Cheers, >> >> Jeff >> >>

March 25, 2016

Re: [Pharo-dev] Fwd: Squeak 5 on Raspberry Pi

by philippe.back＠highoctane.be

yes! Maybe a solid core with a layer of fast evolving things. That's the model for Hortonworks now. A stable Hadoop core for stability and fast updates for things like Spark. Phil On Mar 25, 2016 6:19 PM, "Hilaire" <hilaire(a)drgeo.eu> wrote: > Not exactly related to Announcement, but I remember when I first port > DrGeo to Squeak (at that time Pharo did not exist) I used a lot of > change/update when objects in the canvas changed. It was terribly slow, > and later opted for a top-down update in the list of object. > > So some sometime what look like a cool stuff (decoupled objects) is just > a drag. > > Regarding optimizing, I share my opinion here months ago, I think Pharo > need consolidation releases: no new features, only bugs fix and speed > improvement. There are enough new features in Pharo for a couple of > years, but the product need to *be* solid and *feel* solid. > > Hilaire > > Le 25/03/2016 12:33, Stephan Eggermont a Ã©crit : > > On 25-03-16 11:49, Nicolai Hess wrote: > >> Morphic drasticallly slower ? I would expect morphic code is mostly > >> the same in pharo and squeak. If pharo is slower, this is a good > >> starting point for optimising. Can you gives some hints? > > I do not have the impression that morphic is so much slower. > > We had/have a problem of too many announcements being send and > > too many redraws happening. > > > > Stephan > > > > > > -- > Dr. Geo > http://drgeo.eu > > >

March 25, 2016