December 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Glamour-core maybe missing from Pharo40/main

by Tudor Girba

I agree. Doru On Sat, Dec 6, 2014 at 12:34 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 06 Dec 2014, at 12:21, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > On 06 Dec 2014, at 12:10, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > > On 05 Dec 2014, at 15:30, stepharo <stepharo(a)free.fr> wrote: > > > Le 3/12/14 10:08, Marcus Denker a Ã©crit : > > Yes, seemingly we lost again the repos of external packages... this is a > bug, something in the integraton process resets the reopsitories. > > > Yes because else we can have dangling refs (you remember the mess in > Squeak3.9). > Now this is why we should have package metadata in the image because we > could just reset the repo to their package. > > > I thought that one of the main ideas of versioning systems was that you > keep all the important history things on the server. > > Yes, else the image will grow indefinitely (as it does now). a whole 1/3 > of our image is meta data from Monticello and Scriptloader. > (Pharo4 is 30.9M, but after Scriploader clean and removing MC history, it > is just 22,7MB) > > And this is already with killing this meta data at every release. If we > would keep it, our image would be around 60MB-80MB, that is we > would have 4 times more history data than real data. (and the .changes I > guess far more than 200MB). All this just does not work. > > We need a system that allows sustained growth: meta data of history needs > to be outside on a server. Everything else will not work. > > > One good rule that we should adopt: The artefact of the build server needs > to be the release artefact *with no human intervention at all*. > No âwe remove that before we releaseâ âwe call that method before we > releaseâ. No. Just: What is there is the release. Just that. > > It will serve as a nice forcing function. A .changes with #condenseChanges > called once a year? Nope. > Monticello having history data in the image? Not possible. Scriptlaoder > having all the sets of packages that made every update ever? > Canât be. > > We would have a much better system *and* much less stress when releasing. > > Marcus > -- www.tudorgirba.com "Every thing has its own flow"

Dec. 6, 2014

Re: [Pharo-dev] Glamour-core maybe missing from Pharo40/main

by Marcus Denker

> On 06 Dec 2014, at 12:21, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 06 Dec 2014, at 12:10, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >> >> >>> On 05 Dec 2014, at 15:30, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: >>> >>> >>> Le 3/12/14 10:08, Marcus Denker a Ã©crit : >>>> Yes, seemingly we lost again the repos of external packages... this is a bug, something in the integraton process resets the reopsitories. >>> >>> Yes because else we can have dangling refs (you remember the mess in Squeak3.9). >>> Now this is why we should have package metadata in the image because we could just reset the repo to their package. >> >> I thought that one of the main ideas of versioning systems was that you keep all the important history things on the server. >> > Yes, else the image will grow indefinitely (as it does now). a whole 1/3 of our image is meta data from Monticello and Scriptloader. > (Pharo4 is 30.9M, but after Scriploader clean and removing MC history, it is just 22,7MB) > > And this is already with killing this meta data at every release. If we would keep it, our image would be around 60MB-80MB, that is we > would have 4 times more history data than real data. (and the .changes I guess far more than 200MB). All this just does not work. > > We need a system that allows sustained growth: meta data of history needs to be outside on a server. Everything else will not work. > One good rule that we should adopt: The artefact of the build server needs to be the release artefact *with no human intervention at all*. No âwe remove that before we releaseâ âwe call that method before we releaseâ. No. Just: What is there is the release. Just that. It will serve as a nice forcing function. A .changes with #condenseChanges called once a year? Nope. Monticello having history data in the image? Not possible. Scriptlaoder having all the sets of packages that made every update ever? Canât be. We would have a much better system *and* much less stress when releasing. Marcus

Dec. 6, 2014

Re: [Pharo-dev] Glamour-core maybe missing from Pharo40/main

by Marcus Denker

> On 06 Dec 2014, at 12:10, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > >> On 05 Dec 2014, at 15:30, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: >> >> >> Le 3/12/14 10:08, Marcus Denker a Ã©crit : >>> Yes, seemingly we lost again the repos of external packages... this is a bug, something in the integraton process resets the reopsitories. >> >> Yes because else we can have dangling refs (you remember the mess in Squeak3.9). >> Now this is why we should have package metadata in the image because we could just reset the repo to their package. > > I thought that one of the main ideas of versioning systems was that you keep all the important history things on the server. > Yes, else the image will grow indefinitely (as it does now). a whole 1/3 of our image is meta data from Monticello and Scriptloader. (Pharo4 is 30.9M, but after Scriploader clean and removing MC history, it is just 22,7MB) And this is already with killing this meta data at every release. If we would keep it, our image would be around 60MB-80MB, that is we would have 4 times more history data than real data. (and the .changes I guess far more than 200MB). All this just does not work. We need a system that allows sustained growth: meta data of history needs to be outside on a server. Everything else will not work. Marcus

Dec. 6, 2014

Re: [Pharo-dev] Problem copy pasting from internet browser to GTPlayground

by kilon alios

don't know but what I do know is that I never had such an issue with another programming language or IDE. On Sat, Dec 6, 2014 at 1:11 PM, Max Leske <maxleske(a)gmail.com> wrote: > > On 06 Dec 2014, at 11:47, kilon alios <kilon.alios(a)gmail.com> wrote: > > The problem is not even just MacOS related, I have experienced similar > problems on UBUNTU but in that OS the problem exist when copying from > Chrome it does not exist when copying from Firefox. But in MacOS even > Firefox has the same issue.If I remember correctly Windows has same issues > too. > > Generally speaking the workspace/Playground/Pharo should not allow the > pasting of invisible / illegal characters since they would have no value to > the user. > > > But how do you determine what an âillegal characterâ is? You canât just > exclude control characters or Unicode... > > > On Sat, Dec 6, 2014 at 11:58 AM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >> >> > On 06 Dec 2014, at 10:38, Max Leske <maxleske(a)gmail.com> wrote: >> > >> > >> >> On 05 Dec 2014, at 22:17, kilon alios <kilon.alios(a)gmail.com> wrote: >> >> >> >> I try to copy this code here >> >> >> >> https://www.facebook.com/ObjectProfile/posts/742756179144315 >> >> >> >> and paste it to Playground to do it. It inserts illegal characters. >> >> >> >> I am on MacOS Yosemite and tried Chrome and Safari. >> >> >> >> Workspace also has same issue. Is there a solution to this ? Copy >> pasting code from an internet browser is kinda a huge deal. >> > >> > Confirmed. It seems to be a problem with the # character. Although the >> problem in my opinion is the encoding on the webpage. Workspace and >> Playground behave just as they should (which is to correctly display all >> characters). >> >> I had a look too. There is indeed an issue. You can inspect >> >> Clipboard clipboardText >> >> and you'll see that there are strange characters (probably related to the >> blue) around the symbol constants. Of course, these originate on the page. >> >> But if you copy and paste somewhere else, let's say a terminal (you can >> try the pbpaste command in Mac OS X), these are somehow filtered out, while >> Pharo does not seem to do that. >> >> I vaguely remember that when you copy something, multiple representations >> are actually copied, and during paste you select which one you want. Maybe >> something is wrong there. >> >> But apart from that, I would like to know how the filtering works. >> >> Sven >> >> >> >> >> > >

Dec. 6, 2014

Re: [Pharo-dev] Problem copy pasting from internet browser to GTPlayground

by Max Leske

> On 06 Dec 2014, at 11:47, kilon alios <kilon.alios(a)gmail.com> wrote: > > The problem is not even just MacOS related, I have experienced similar problems on UBUNTU but in that OS the problem exist when copying from Chrome it does not exist when copying from Firefox. But in MacOS even Firefox has the same issue.If I remember correctly Windows has same issues too. > > Generally speaking the workspace/Playground/Pharo should not allow the pasting of invisible / illegal characters since they would have no value to the user. But how do you determine what an âillegal characterâ is? You canât just exclude control characters or Unicode... > > On Sat, Dec 6, 2014 at 11:58 AM, Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: > > > On 06 Dec 2014, at 10:38, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: > > > > > >> On 05 Dec 2014, at 22:17, kilon alios <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>> wrote: > >> > >> I try to copy this code here > >> > >> https://www.facebook.com/ObjectProfile/posts/742756179144315 <https://www.facebook.com/ObjectProfile/posts/742756179144315> > >> > >> and paste it to Playground to do it. It inserts illegal characters. > >> > >> I am on MacOS Yosemite and tried Chrome and Safari. > >> > >> Workspace also has same issue. Is there a solution to this ? Copy pasting code from an internet browser is kinda a huge deal. > > > > Confirmed. It seems to be a problem with the # character. Although the problem in my opinion is the encoding on the webpage. Workspace and Playground behave just as they should (which is to correctly display all characters). > > I had a look too. There is indeed an issue. You can inspect > > Clipboard clipboardText > > and you'll see that there are strange characters (probably related to the blue) around the symbol constants. Of course, these originate on the page. > > But if you copy and paste somewhere else, let's say a terminal (you can try the pbpaste command in Mac OS X), these are somehow filtered out, while Pharo does not seem to do that. > > I vaguely remember that when you copy something, multiple representations are actually copied, and during paste you select which one you want. Maybe something is wrong there. > > But apart from that, I would like to know how the filtering works. > > Sven > > > > >

Dec. 6, 2014

Re: [Pharo-dev] Glamour-core maybe missing from Pharo40/main

by Yuriy Tymchuk

> On 05 Dec 2014, at 15:30, stepharo <stepharo(a)free.fr> wrote: > > > Le 3/12/14 10:08, Marcus Denker a Ã©crit : >> Yes, seemingly we lost again the repos of external packages... this is a bug, something in the integraton process resets the reopsitories. > > Yes because else we can have dangling refs (you remember the mess in Squeak3.9). > Now this is why we should have package metadata in the image because we could just reset the repo to their package. I thought that one of the main ideas of versioning systems was that you keep all the important history things on the server. Uko >> >> On Sat, Nov 29, 2014 at 7:53 AM, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: >> >> Sometimes when I am hacking around the system, I use Monticello to review just what I've changed. >> >> In build 40390, I did a <Changes> >> of Glamour-Core (BernardoContreras.286) against Pharo40/main and got _lots_ of changes. Then it seems that this package is not in Pharo40/main. Should it be? >> >> Maybe this is because its an external package - but then its repository is not listed? >> >> cheers -ben >> >> >> >> >

Dec. 6, 2014

Re: [Pharo-dev] Problem copy pasting from internet browser to GTPlayground

by kilon alios

The problem is not even just MacOS related, I have experienced similar problems on UBUNTU but in that OS the problem exist when copying from Chrome it does not exist when copying from Firefox. But in MacOS even Firefox has the same issue.If I remember correctly Windows has same issues too. Generally speaking the workspace/Playground/Pharo should not allow the pasting of invisible / illegal characters since they would have no value to the user. On Sat, Dec 6, 2014 at 11:58 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 06 Dec 2014, at 10:38, Max Leske <maxleske(a)gmail.com> wrote: > > > > > >> On 05 Dec 2014, at 22:17, kilon alios <kilon.alios(a)gmail.com> wrote: > >> > >> I try to copy this code here > >> > >> https://www.facebook.com/ObjectProfile/posts/742756179144315 > >> > >> and paste it to Playground to do it. It inserts illegal characters. > >> > >> I am on MacOS Yosemite and tried Chrome and Safari. > >> > >> Workspace also has same issue. Is there a solution to this ? Copy > pasting code from an internet browser is kinda a huge deal. > > > > Confirmed. It seems to be a problem with the # character. Although the > problem in my opinion is the encoding on the webpage. Workspace and > Playground behave just as they should (which is to correctly display all > characters). > > I had a look too. There is indeed an issue. You can inspect > > Clipboard clipboardText > > and you'll see that there are strange characters (probably related to the > blue) around the symbol constants. Of course, these originate on the page. > > But if you copy and paste somewhere else, let's say a terminal (you can > try the pbpaste command in Mac OS X), these are somehow filtered out, while > Pharo does not seem to do that. > > I vaguely remember that when you copy something, multiple representations > are actually copied, and during paste you select which one you want. Maybe > something is wrong there. > > But apart from that, I would like to know how the filtering works. > > Sven > > > > >

Dec. 6, 2014

Re: [Pharo-dev] How can I specify the bindings when evaluating an expression?

by Marcus Denker

> On 05 Dec 2014, at 15:18, stepharo <stepharo(a)free.fr> wrote: > > I would like to be able to express > > Compiler new > bindings: { a -> 3. b -> 4}; > evaluate: 'a + b'; > result > and get 7 > > How can I do that? > Not directly, as evaluate is just a doitâ¦ but it can be added as the machinery is there for evaluating in context in the debugger. I will have a look but not this weekend. Marcus

Dec. 6, 2014

Re: [Pharo-dev] [pharo-project/pharo-core] e1a077: 40402

by Sven Van Caekenberghe

> On 06 Dec 2014, at 11:02, GitHub <noreply(a)github.com> wrote: > > Log Message: > ----------- > 40402 > 14566 ShoreLine Reporter Integration > https://pharo.fogbugz.com/f/cases/14566 Great work, Marcus, this was a difficult one. Thanks for your persistence. Sven

Dec. 6, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40402 Home: https://github.com/pharo-project/pharo-core

Dec. 6, 2014