- Pharo-dev - lists.pharo.org

Little feature for ConfigurationBrowser

by stepharo

Hi T. would it be possible to get a menu that creates the repo in the MC Browser from the ConfigurationBrowser like that people will be able to push their configuration without having to create all the repo manually? Stef

Dec. 6, 2014

Re: [Pharo-dev] default fonts changed in Pharo 4.0

by stepharo

It would be good to avoid to duplicate the font description as binary and the font description as object. It would be nice to also have a nice way to import font from the ttf description files. This is what we should put on a server not pharo method containaing binary. Stef

Dec. 6, 2014

Re: [Pharo-dev] 12854 TestRunner>>categorySelected hard coded zero

by stepharo

sometimes this is because when you click on the other list you need to reset or something like that? Le 2/12/14 16:07, Ben Coman a Ã©crit : > > Anyone know why TestRunner>>categorySelected was hard coded to return > zero? It breaks shift-click multiple selection in TestRunner. > > Seems we've lived with it a long time... > * Version info --> "lr 10/31/2005 15:11" > > btw, SystemReporter>>categorySelected method is identical > * Hardcoded to return zero > * Version info --> "lr 10/31/2005 15:11" > > maybe one class was copied to the other? > > cheers -ben > > Fix submitted... > https://pharo.fogbugz.com/default.asp?12854 > >

Dec. 6, 2014

Re: [Pharo-dev] default fonts changed in Pharo 4.0

by stepharo

Hi Juraj Excellent. I would like to have a nice way to import ttf and install not an horrible method full of binary data but a method that load a ttf and that creates font description directly. And as Pharo we should have a simple font ttf file server. Stef Le 2/12/14 15:02, Juraj Kubelka a Ã©crit : > I am not sure if I follow the discussion, but next week I am planning to extract embedded fonts and make a new embedded provider. The current solution I have made recently is too tight, there are cyclic dependencies between free font type provider and embedded fonts and it causes problems. > > Cheers, > Juraj > >> On Dec 2, 2014, at 9:36 AM, Sven Van Caekenberghe<sven(a)stfx.eu> wrote: >> >> Esteban, >> >> Did you look/read what Juraj Kubelka did ? >> >> Like this issue, but there are others too: >> >> https://pharo.fogbugz.com/f/cases/13967 >> >> I vaguely remember he found something wrt initialization, maybe Marcus remembers. >> >> Sven >> >>> On 02 Dec 2014, at 13:10, Esteban Lorenzano<estebanlm(a)gmail.com> wrote: >>> >>> â¦ and I lost fonts again :( >>> I made an integration and fonts got lostâ¦ Iâm reviving issue, and working on it :( >>> >>> Esteban >>> >>>> On 02 Dec 2014, at 12:47, Sven Van Caekenberghe<sven(a)stfx.eu> wrote: >>>> >>>>> On 02 Dec 2014, at 12:12, Esteban Lorenzano<estebanlm(a)gmail.com> wrote: >>>>> >>>>>> On 02 Dec 2014, at 12:02, Sven Van Caekenberghe<sven(a)stfx.eu> wrote: >>>>>> >>>>>> >>>>>>> On 02 Dec 2014, at 11:46, Tudor Girba<tudor(a)tudorgirba.com> wrote: >>>>>>> >>>>>>> There is no Source Code Sans :). There is only "Source Sans Pro" or "Source Code Pro". >>>>>> Yes, right now in the latest 4.0. >>>>>> >>>>>> But there used to be a different one, that is the one I am using, see screenshot (http://www.google.com/fonts/specimen/Open+Sans) I don't remember where I got it from (Igor is the author), but I have been using it for months. >>>>> no, it was me the authorâ¦ and it was a mistake I made first time thatâs why I removed it (but I can package it and put it somewhere anywayâ¦ I was even thinking on create a âFont Repositoryâ where put different fonts, until I found this:http://smalltalkhub.com/#!/~girba/FreeFonts which is a cool repo, but does not works completely along our versionâ¦ we will need to merge :P) >>>> Maybe it would be even better if there was code in the image to make these embedded fonts yourself (or a comment). >>>> >>>>>> My question was, why choose one above the other ? >>>>> I replaced it with the Source Sans Pro because same family fonts works better together (Source * Pro) >>>> OK. It seems to have a smaller width, we'll see. >>>> >>>>> cheers, >>>>> Esteban >>>>> >>>>>> <Screen Shot 2014-12-02 at 11.57.13.png> >>>>>> >>>>>>> Doru >>>>>>> >>>>>>> On Tue, Dec 2, 2014 at 11:35 AM, Sven Van Caekenberghe<sven(a)stfx.eu> wrote: >>>>>>> What is the difference between 'Open Sans' and 'Source Code Sans' ? >>>>>>> >>>>>>> I am using the former in my 3.0 image, and I like it a bit more, it seems a bit wider. >>>>>>> >>>>>>>> On 02 Dec 2014, at 11:27, Tudor Girba<tudor(a)tudorgirba.com> wrote: >>>>>>>> >>>>>>>> Great! >>>>>>>> >>>>>>>> Doru >>>>>>>> >>>>>>>> p.s. Finally :) >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Dec 2, 2014 at 9:48 AM, Esteban Lorenzano<estebanlm(a)gmail.com> wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> We changed the default fonts in Pharo for the ones that are used normally in Moose. >>>>>>>> They are: Source Sans Pro and Source Code Pro. >>>>>>>> We needed to do it for several reasons: >>>>>>>> >>>>>>>> 1) TxText (the new text model) is cairo based, and cairo just can work with real fonts, so we need them as default (now we will be able to integrate TxText and start the replace of old editors) >>>>>>>> 2) Current fonts takes too much space and do not scales fine (at least that Iâve been told) >>>>>>>> >>>>>>>> So, well, thatâ¦ you will see âsomething differentâ when you download latest image version :) >>>>>>>> >>>>>>>> cheers, >>>>>>>> Esteban >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> www.tudorgirba.com >>>>>>>> >>>>>>>> "Every thing has its own flow" >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> www.tudorgirba.com >>>>>>> >>>>>>> "Every thing has its own flow" >

Dec. 6, 2014

Re: [Pharo-dev] GetOpt

by stepharo

Can you be more concrete because I like what Camillo designed. Le 2/12/14 16:06, Sean P. DeNigris a Ã©crit : > EstebanLM wrote >> is cool. >> I would like to explore the possibility to replace our command line parser >> with getopt. You knowâ¦ is more compatible at the end :) > I find the implementation of our command line handlers very confusing. It > seems like it grew organically from a smaller idea and the design got out of > control. There are many assumptions that can make it hard to extend, > especially to combine multiple options, as Ben and I discovered when > implementing the "don't run startup scripts" handler. It would be nice to > revisit starting from a behavioral specification. > > > > ----- > Cheers, > Sean > -- > View this message in context:http://forum.world.st/GetOpt-tp4793474p4793621.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

Dec. 6, 2014

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