- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Color yzw

by Dimitris Chloupis

and so is auto completion ;) On Sat, Jan 16, 2016 at 1:03 PM stepharo <stepharo(a)free.fr> wrote: > How can we proceed? > Because this coloring functionality is really important. > > Stef > > > anyone an idea? > > I'm trying to think. > Looks like it would be good to be able to make a distinction between > symbols and selectors (selectors installed > in method dictionaries) > > > yes, this would improve code completion a bit, too, as there are more > symbols than symbols that are actually names > of methods. > > The data could be created per environment (Smalltalk globals) the first > time and then cached till shutdown. > (it would be an array of size 46451, pointing to existing symbols). > > The environment could cache sent selectors, tooâ¦ pablo did an experiment > with that. > > Marcus > > >

Jan. 16, 2016

Re: [Pharo-dev] Contributing to Pharo

by David Allouche

> On 16 Jan 2016, at 12:14, stepharo <stepharo(a)free.fr> wrote: > > Le 16/1/16 09:59, David Allouche a Ã©crit : >> >> But, really, this "list of dirty packages" should really only list dirty packages. What is the use case for selecting a non-dirty package? > > because you never know > Sometimes you save a package then you do a slice and you should be able to decide. That does not make sense to me. I guess it will, when I understand Monticello better.

Jan. 16, 2016

Re: [Pharo-dev] Contributing to Pharo

by David Allouche

> On 16 Jan 2016, at 12:12, stepharo <stepharo(a)free.fr> wrote: >>> On 16 Jan 2016, at 02:42, Ben Coman <btc(a)openinworld.com> wrote: >>> >>> So if occasionally if everything seems against you, after trying a >>> fresh Image as you already did, slide back to the last build that >>> worked for you (I don't think the issues you experience are Spur >>> related, but 50496 might be a good fallback as Pre-Spur and >>> Pre-GTDebugger). Then create a fresh Image from the latest build to >>> test your Slice and in that time maybe the other issues have gone. >> Ok. So my earlier question (in Slack, I think) about how "unstable" is unstable in Pharo is now answered. It's really unstable, not "Debian-like unstable". > > No this is not really the case. In general we try hard to get alpha stable after you get some hiccups. > This is not every day that we change FFI, GC, object internal representations and the text editors, syntax highli > And our problems is that sometimes often we just jump over glitches (this is why I'm getting mad because when I do videos > or other I see them in my face). Now I would love to have task forces that check glitches. I get the picture now. I just checked in when the lobby, the roof and the plumbing of the hotel were undergoing renovations: it's not how it is usually. I could question whether it's a good idea to cram so much in a single release cycle. But release management is a difficult topic, and often there is no good solution, just one that has less downsides than the others. Cheers.

Jan. 16, 2016

Re: [Pharo-dev] Contributing to Pharo

by stepharo

Le 16/1/16 09:59, David Allouche a Ã©crit : >> On 16 Jan 2016, at 02:15, Ben Coman <btc(a)openinworld.com >> <mailto:btc@openinworld.com>> wrote: >> On Sat, Jan 16, 2016 at 3:45 AM, David Allouche<david(a)allouche.net >> <mailto:david@allouche.net>>wrote: >> >> 1. it shows a bunch of packages I have not touched >> 2. it does not show the package that contains my fix (Spec-Tools) >> >> >> I am curious on item 2. Was this just because the dirty package was >> sorted to the top of the list (per Nicolai's snapshots)? > > I think that was indeed the source of confusion. > > But, really, this "list of dirty packages" should really only list > dirty packages. What is the use case for selecting a non-dirty package? because you never know Sometimes you save a package then you do a slice and you should be able to decide. > >> I looked in the world menu, and I found this menu item called >> "Komitter". That sounded like a good candidate. >> >> >> I see how the term "Commit" is misleading here without context. >> Probably "Press the <Save> button to commit your slice to the inbox >> repository" would probably be better. > > Yes, that would help, too. > >> https://pharo.fogbugz.com/default.asp?17398 > > Cool! >

Jan. 16, 2016

Re: [Pharo-dev] Contributing to Pharo

by stepharo

Hi david >> On 16 Jan 2016, at 02:42, Ben Coman <btc(a)openinworld.com> wrote: >> >> So if occasionally if everything seems against you, after trying a >> fresh Image as you already did, slide back to the last build that >> worked for you (I don't think the issues you experience are Spur >> related, but 50496 might be a good fallback as Pre-Spur and >> Pre-GTDebugger). Then create a fresh Image from the latest build to >> test your Slice and in that time maybe the other issues have gone. > Ok. So my earlier question (in Slack, I think) about how "unstable" is unstable in Pharo is now answered. It's really unstable, not "Debian-like unstable". No this is not really the case. In general we try hard to get alpha stable after you get some hiccups. This is not every day that we change FFI, GC, object internal representations and the text editors, syntax highli And our problems is that sometimes often we just jump over glitches (this is why I'm getting mad because when I do videos or other I see them in my face). Now I would love to have task forces that check glitches. > > It would also be nice to add some public info about that. I'll create an issue. > > At the moment, I am stuck with GTDebugger, because it seems the old debugger does not have any keyboard shortcut form stepping through code. And that's something I would really really miss. So I'll suffer the pain of all the other glitches, and see how that goes. >

Jan. 16, 2016

Re: [Pharo-dev] Contributing to Pharo

by stepharo

Le 16/1/16 00:15, Henrik Sperre Johansen a Ã©crit : > Or, try a stable release. > Whenever I try developing on the latest version, I end up getting > disrupted by bugs in the core tools 70-80% of the time. > For released versions, in 1.4 it was maybe 5%, in 2.0 40%, in 3.0 20%, > in 4.0 10% > So at least it's been trending downwards, though I expect a totally > new debugger, image format, RBParser unification and new FFI in 5.0 > will keep causing problems for a quite a while. > Yes the point is really to understand that we changed a lot of things because they had to. So this is important to put bugs in perspective to changes. Now we should improve the test coverage too Stef

Jan. 16, 2016

Re: [Pharo-dev] [Vm-dev] Unable to read Utf8 ?

by Esteban Lorenzano

> On 16 Jan 2016, at 11:59, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Le 16/01/2016 11:39, Esteban Lorenzano a Ã©crit : >> >>> On 16 Jan 2016, at 10:45, Eliot Miranda <eliot.miranda(a)gmail.com> >>> wrote: >>> >>> >>> Hi Thierry, >>> >>> up until a few hours ago the latest VM sources were indeed broken >>> by work I was doing on 64 bits. My sources are AFAIA now correct >>> and I suppose you're waiting on Esteban doing a merge. But I'm >>> responding since there seems to be a process error here. >> >> is still broken :) >> >>> >>> I need the freedom to break the VM, otherwise I can only extend it >>> with difficulty. This assumes that there are currently servers >>> that build and test the VM, and implies that we maintain the notion >>> of the most recent good VM that has passed all the tests, and that >>> this is the "latest" VM everyone is using. >>> >>> If there isn't this distinction then every time I extend the VM and >>> make inevitable mistakes I affect users. That's clearly not >>> sensible. >> >> yes of course, what we have is two versions of the VM: >> >> - âlatest" build is a build with latest sourcesâ¦ this might be >> broken. People willing to help us find bugs should use this. - >> âstableâ build is the VM after it passed all testsâ¦ and thatâs what >> people willing some stability should use :) >> >> what actually is happening now is that there is a lot of people >> helping in the migration of spur (something I thank, a lot) and then >> they use latest vm versionâ¦ who is usually very stable (but not >> always, as is the case). > > I think the issue was that the latest vm has been very stable and that it suddenly broke was a bit unexpected. At the same time, in the pre-spur days, the stable was a very old build. yes, true. Now latest spur stable is from 14/01 soâ¦ :P Esteban > > Thierry > >> cheers, Esteban >> >> >>> >>> _,,,^..^,,,_ (phone) >>> >>>> On Jan 16, 2016, at 1:21 AM, Thierry Goubier >>>> <thierry.goubier(a)gmail.com> wrote: >>>> >>>> Hi Guys, >>>> >>>> has something changed in string handling? I'm unable to get the >>>> latest Pharo to read files containing utf8 data. >>>> >>>> I tracked it down to a primitive (at:put:) in WideString and to >>>> the latest vm for Pharo 5, so, maybe there is something wrong in >>>> the latest vm. >>>> >>>> Thierry

Jan. 16, 2016

Re: [Pharo-dev] Color yzw

by stepharo

How can we proceed? Because this coloring functionality is really important. Stef > >>> anyone an idea? >>> >> I'm trying to think. >> Looks like it would be good to be able to make a distinction between >> symbols and selectors (selectors installed >> in method dictionaries) >> > > yes, this would improve code completion a bit, too, as there are more > symbols than symbols that are actually names > of methods. > > The data could be created per environment (Smalltalk globals) the > first time and then cached till shutdown. > (it would be an array of size 46451, pointing to existing symbols). > > The environment could cache sent selectors, tooâ¦ pablo did an > experiment with that. > > Marcus >

Jan. 16, 2016

Re: [Pharo-dev] [Vm-dev] Unable to read Utf8 ?

by Thierry Goubier

Le 16/01/2016 11:39, Esteban Lorenzano a Ã©crit : > >> On 16 Jan 2016, at 10:45, Eliot Miranda <eliot.miranda(a)gmail.com> >> wrote: >> >> >> Hi Thierry, >> >> up until a few hours ago the latest VM sources were indeed broken >> by work I was doing on 64 bits. My sources are AFAIA now correct >> and I suppose you're waiting on Esteban doing a merge. But I'm >> responding since there seems to be a process error here. > > is still broken :) > >> >> I need the freedom to break the VM, otherwise I can only extend it >> with difficulty. This assumes that there are currently servers >> that build and test the VM, and implies that we maintain the notion >> of the most recent good VM that has passed all the tests, and that >> this is the "latest" VM everyone is using. >> >> If there isn't this distinction then every time I extend the VM and >> make inevitable mistakes I affect users. That's clearly not >> sensible. > > yes of course, what we have is two versions of the VM: > > - âlatest" build is a build with latest sourcesâ¦ this might be > broken. People willing to help us find bugs should use this. - > âstableâ build is the VM after it passed all testsâ¦ and thatâs what > people willing some stability should use :) > > what actually is happening now is that there is a lot of people > helping in the migration of spur (something I thank, a lot) and then > they use latest vm versionâ¦ who is usually very stable (but not > always, as is the case). I think the issue was that the latest vm has been very stable and that it suddenly broke was a bit unexpected. At the same time, in the pre-spur days, the stable was a very old build. Thierry > cheers, Esteban > > >> >> _,,,^..^,,,_ (phone) >> >>> On Jan 16, 2016, at 1:21 AM, Thierry Goubier >>> <thierry.goubier(a)gmail.com> wrote: >>> >>> Hi Guys, >>> >>> has something changed in string handling? I'm unable to get the >>> latest Pharo to read files containing utf8 data. >>> >>> I tracked it down to a primitive (at:put:) in WideString and to >>> the latest vm for Pharo 5, so, maybe there is something wrong in >>> the latest vm. >>> >>> Thierry >>> > > >

Jan. 16, 2016

Re: [Pharo-dev] [Vm-dev] Unable to read Utf8 ?

by Esteban Lorenzano

> On 16 Jan 2016, at 11:39, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > >> On 16 Jan 2016, at 10:45, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> >> Hi Thierry, >> >> up until a few hours ago the latest VM sources were indeed broken by work I was doing on 64 bits. My sources are AFAIA now correct and I suppose you're waiting on Esteban doing a merge. But I'm responding since there seems to be a process error here. > > is still broken :) btwâ¦ Iâm not merging anymore VMMaker packages, they are taken and built âas isâ (I worked a lot to get back to this, heh) :) this is what âlatestâ vm is. what happens is that time to time I still have to merge platform sourcesâ¦ but I made that Thursday so we are ok (just verified). Anyway, it is still broken :( > >> >> I need the freedom to break the VM, otherwise I can only extend it with difficulty. This assumes that there are currently servers that build and test the VM, and implies that we maintain the notion of the most recent good VM that has passed all the tests, and that this is the "latest" VM everyone is using. >> >> If there isn't this distinction then every time I extend the VM and make inevitable mistakes I affect users. That's clearly not sensible. > > yes of course, what we have is two versions of the VM: > > - âlatest" build is a build with latest sourcesâ¦ this might be broken. People willing to help us find bugs should use this. > - âstableâ build is the VM after it passed all testsâ¦ and thatâs what people willing some stability should use :) > > what actually is happening now is that there is a lot of people helping in the migration of spur (something I thank, a lot) and then they use latest vm versionâ¦ who is usually very stable (but not always, as is the case). > > cheers, > Esteban > > >> >> _,,,^..^,,,_ (phone) >> >>> On Jan 16, 2016, at 1:21 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >>> >>> Hi Guys, >>> >>> has something changed in string handling? I'm unable to get the latest Pharo to read files containing utf8 data. >>> >>> I tracked it down to a primitive (at:put:) in WideString and to the latest vm for Pharo 5, so, maybe there is something wrong in the latest vm. >>> >>> Thierry >>> >

Jan. 16, 2016