April 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Fwd: Old bugs fixed by Opal

by Marcus Denker

On Apr 19, 2013, at 12:10 PM, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On Apr 19, 2013, at 9:37 AM, Marcus Denker wrote: > >> Maybe of general interestâ¦ >> >> >> Begin forwarded message: >> >>> Hi, >>> >>> These just work with Opal correctly: >>> >>> 7202 Errors when debugging inlined values >>> https://pharo.fogbugz.com/f/cases/7202 >>> >>> 750 Debugger highlight bug >>> https://pharo.fogbugz.com/f/cases/750 >>> >>> :-) >>> >>> Marcus >> >> >> (The list is here: >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-compiler >> >> but this is more for boring things, e.g. commits to the repo and issue tracker status mails) >> >> Marcus > Oooooh, I *hate* 750! > > Tested it (ClosureTests new testToDoOutsideTemp -> debug) in the latest nightly, after switching to Opal the to:do: scope was indeed highlighted correctly :D > .. however, I could not go into/over/through without incorrect highlighting/eventual error, I presume that is what the fix mentioned in issue coming later today is for? Did you use https://ci.inria.fr/rmod/job/Opal/ The Opal in the image is a bit out-datedâ¦ (and I am sure you will find more bugsâ¦) Marcus

April 19, 2013

Re: [Pharo-project] Fwd: Old bugs fixed by Opal

by Henrik Johansen

On Apr 19, 2013, at 9:37 AM, Marcus Denker wrote: > Maybe of general interestâ¦ > > > Begin forwarded message: > >> Hi, >> >> These just work with Opal correctly: >> >> 7202 Errors when debugging inlined values >> https://pharo.fogbugz.com/f/cases/7202 >> >> 750 Debugger highlight bug >> https://pharo.fogbugz.com/f/cases/750 >> >> :-) >> >> Marcus > > > (The list is here: > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-compiler > > but this is more for boring things, e.g. commits to the repo and issue tracker status mails) > > Marcus Oooooh, I *hate* 750! Tested it (ClosureTests new testToDoOutsideTemp -> debug) in the latest nightly, after switching to Opal the to:do: scope was indeed highlighted correctly :D .. however, I could not go into/over/through without incorrect highlighting/eventual error, I presume that is what the fix mentioned in issue coming later today is for? Cheers, Henry

April 19, 2013

Re: [Pharo-project] [Seaside] Re: Has anyone used Zodiac and Seaside to for https?

by Esteban Lorenzano

On Apr 19, 2013, at 12:59 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 18 April 2013 23:46, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> Igor, >> >> On 18 Apr 2013, at 23:21, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> why? >>> anything i can help with? >> >> Well, last time I looked (eons ago), in the C code of the Mac SSL plugin, the certificate was not used/implemented. >> >> For starters, follow ZdcPluginSSLSession>>#certiificate[:] to find the primitive. >> >> Then see ihow/if that actually does something and/or is being used - in the C/plugin code. >> >> It would be really great if we could fix this. >> > For some reason i was thinking that we already using bundled SSL libs > for Mac VM. we are. but I remember there where a problem with certificates and mac... > (so plugin works with vanilla ssl library on all platforms). > Not true. We should fix that: it worked for windows, don't see why it > won't work for Mac. > I added this to my todo list. > >> Sven >> >> >> -- >> Sven Van Caekenberghe >> Proudly supporting Pharo >> http://pharo.org >> http://association.pharo.org >> http://consortium.pharo.org >> >> >> >> >> _______________________________________________ >> seaside mailing list >> seaside(a)lists.squeakfoundation.org >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > > > -- > Best regards, > Igor Stasenko. > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

April 19, 2013

Re: [Pharo-project] Argument names created by Debugger

by Esteban Lorenzano

finally, someone with a sense of opportunity :) +100 On Apr 19, 2013, at 5:39 AM, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > Frank Shearar-3 wrote >> You could add Boolean as well, to avoid creating a name like 'aTrue'. > > Ooh, good idea! Okay, there's obviously enough interest. I'll get on it... > > https://pharo.fogbugz.com/f/cases/10314/Debugger-create-better-argument-nam… > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Argument-names-created-by-Debugger-tp4682387p4682445.… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

April 19, 2013

Re: [Pharo-project] Pharo on iOS with Bluetooth keyboard working almost in full.

by Esteban Lorenzano

sweet :) On Apr 19, 2013, at 12:00 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > I've made some progress on using the external keyboard. > > Now, it is about usable. Some mappings still missing (discovering a lot of interesting things in the process) but usable. > > See video (poor camera, but the better one is on the iPad, oops): > > http://www.youtube.com/watch?v=7MNsUiCc5FQ > > Phil

April 19, 2013

Re: [Pharo-project] files.pharo.org: Moving to new server

by Marcus Denker

On Apr 19, 2013, at 7:55 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Apr 18, 2013, at 5:43 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> On Apr 18, 2013, at 3:01 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >>> Hi, >>> >>> We will change the DNS to a new server. >>> >>> This should be transparent, but of course we never knowâ¦ >>> >>> Stages: >>> >>> 1) Change DNS to point to new server of (TODAY) >>> files.pharo.org >>> get.pharo.org >>> updates.pharo.org >>> >> >> Success! DNS has propagated (at least to here) and it works. >> I should be more reliable and faster. > > What is missing is the Platforms Dirâ¦ > > http://files.pharo.org/platform/Pharo3.0-mac.zip > > Will be fixed soonâ¦ > Camillo fixed it. Next: DNS Server (after Lunch). This might impact the URL forwards ci.pharo.org pharo.org as forwarding is done differently on the new setup. Marcus

April 19, 2013

Re: [Pharo-project] Metacello configuration conventions

by Frank Shearar

On 19 April 2013 09:55, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2013-04-19, at 10:36, Diego Lont <diego.lont(a)delware.nl> wrote: > >> Hi all, >> >> I just want to add another thought to the convention discussion. >> >> In my work process I have two different activities when deploying new code: >> 1) I want to deploy a patch, that only includes the bugfix. >> 2) I want to deploy a release, that includes all updates. >> >> In the first I usually do not want to upgrade dependencies. If dependencies need upgrading I want to make this decision manually. >> >> In the second I usually want to upgrade dependencies. If dependencies need upgrading this should be done automatically. >> >> Metacello supports both, but not at the same time. Either you mark your configuration with fixed versions (best for patches) or with symbolic versions (best for releases). >> >> Currently we have a baseline, a version, and groups that I can edit. I think I want a third thing: the deployment, where I describe certain deployment strategies. So that I can say: >> ConfigurationOfMyProject project stableVersion patch load >> ConfigurationOfMyProject project stableVersion loadRelease >> or something like this. >> >> Cheers, >> Diego > > I think you should never hardcode dependencies (well major version number of course)... > but otherwise this is exactly what ruby gems's [1] version constraints will do (~> and friends) I agree with the idea: you'd automatically pull in bugfixes and such. However, there's now also nothing protecting you from being bitten by people not following semantic versioning, accidental regressions in your dependencies, new bugs, ... You make your builds unrepeatable. The point of a Gemfile.lock is to turn your ~> dependencies in your Gemfile into hard dependencies, so you can control this accidental uprev. Or, at the least, show the uprev explicitly. But Gemfile.lock only gets refreshed when you "bundle install" or "bundle update", so do also get to _decide_ whether or not to uprev. frank > For the inverse, I think that's what you mention, something like Versionner is the only solution. > Since you will have to traverse all dependencies and see which new versions got released > and which ones you want to newly depend on... > > > [1] http://docs.rubygems.org/read/chapter/16

April 19, 2013

Re: [Pharo-project] Metacello configuration conventions

by Camillo Bruni

On 2013-04-19, at 10:36, Diego Lont <diego.lont(a)delware.nl> wrote: > Hi all, > > I just want to add another thought to the convention discussion. > > In my work process I have two different activities when deploying new code: > 1) I want to deploy a patch, that only includes the bugfix. > 2) I want to deploy a release, that includes all updates. > > In the first I usually do not want to upgrade dependencies. If dependencies need upgrading I want to make this decision manually. > > In the second I usually want to upgrade dependencies. If dependencies need upgrading this should be done automatically. > > Metacello supports both, but not at the same time. Either you mark your configuration with fixed versions (best for patches) or with symbolic versions (best for releases). > > Currently we have a baseline, a version, and groups that I can edit. I think I want a third thing: the deployment, where I describe certain deployment strategies. So that I can say: > ConfigurationOfMyProject project stableVersion patch load > ConfigurationOfMyProject project stableVersion loadRelease > or something like this. > > Cheers, > Diego I think you should never hardcode dependencies (well major version number of course)... but otherwise this is exactly what ruby gems's [1] version constraints will do (~> and friends) For the inverse, I think that's what you mention, something like Versionner is the only solution. Since you will have to traverse all dependencies and see which new versions got released and which ones you want to newly depend on... [1] http://docs.rubygems.org/read/chapter/16

April 19, 2013

Re: [Pharo-project] Metacello configuration conventions

by Diego Lont

Hi all, I just want to add another thought to the convention discussion. In my work process I have two different activities when deploying new code: 1) I want to deploy a patch, that only includes the bugfix. 2) I want to deploy a release, that includes all updates. In the first I usually do not want to upgrade dependencies. If dependencies need upgrading I want to make this decision manually. In the second I usually want to upgrade dependencies. If dependencies need upgrading this should be done automatically. Metacello supports both, but not at the same time. Either you mark your configuration with fixed versions (best for patches) or with symbolic versions (best for releases). Currently we have a baseline, a version, and groups that I can edit. I think I want a third thing: the deployment, where I describe certain deployment strategies. So that I can say: ConfigurationOfMyProject project stableVersion patch load ConfigurationOfMyProject project stableVersion loadRelease or something like this. Cheers, Diego

April 19, 2013

Re: [Pharo-project] [Athens] A new wave of impressionism

by Camillo Bruni

cool! too bad I was not that well yesterday, but I enjoyed our geometry deciphering session on the whiteboard! :) On 2013-04-19, at 06:55, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > :) > This is cool that you push athens. > Because this is really important for Pharo. > > Stef > >> Not really impressive (that's why it called new wave) >> >> Here is results of 2 days of preparing/implementing and polishing a >> quadric bezier curve approximation >> algorithm by series of lines. >> >> The red pill.. err fill is polygon consisting purely from lines, >> the white outline is same quadric bezier, but drawn directly by cairo >> with stroke width = 5. >> >> Cubic bezier , then elliptical arc and then generic parametric >> functions ahead! :) >> >> There is two reasons why i implementing highly inefficient (because of >> boxed floats) >> path flattener: >> - some path segments are not supported by cairo, therefore i am >> forced to approximate it with something else (and something else is >> lines ;) >> - having path geometry turned into silly polygon, there is very easy >> algorithm to tell if given point inside or outside of polygon >> >> so, potentially, this will give use following: >> - being able to use any kind of curves as path segments (well, it >> could be a bit slow, but it is up to you, right?) e.g. something like: >> builder >> lineTo: 50@50; >> parametricCurve: [:t | t sin * t squared ] tMin: 0 tMax: 10 to: 20@30 >> >> - being able to detect whether mouse hovers over shape or not :) >> >> >> -- >> Best regards, >> Igor Stasenko. >> <Screen Shot 2013-04-18 at 10.43.07 PM.png> > >

April 19, 2013