October 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [pharo-project/pharo-core] 7c58b1: 50369

by Esteban Lorenzano

it says it did it, but actually it doesnât :P trying again :) > On 07 Oct 2015, at 10:01, GitHub <noreply(a)github.com> wrote: > > Branch: refs/heads/5.0 > Home: https://github.com/pharo-project/pharo-core > Commit: 7c58b1be0d0f72a2cdbb0f90ec6c374178b88efd > https://github.com/pharo-project/pharo-core/commit/7c58b1be0d0f72a2cdbb0f90… > Author: Jenkins Build Server <board(a)pharo-project.org> > Date: 2015-10-07 (Wed, 07 Oct 2015) > > Changed paths: > R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50368.st > A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50369.st > R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50368.st > A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50369.st > M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st > > Log Message: > ----------- > 50369 > 16732 DNU when cancel fetch on retrieve icon sets > https://pharo.fogbugz.com/f/cases/16732 > > 16577 Random should be in its own package > https://pharo.fogbugz.com/f/cases/16577 > > 16726 move Reflectivity-Styling to a separate package > https://pharo.fogbugz.com/f/cases/16726 > > http://files.pharo.org/image/50/50369.zip > >

Oct. 7, 2015

[pharo-project/pharo-core]

by GitHub

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

Oct. 7, 2015

[pharo-project/pharo-core] 7c58b1: 50369

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 7c58b1be0d0f72a2cdbb0f90ec6c374178b88efd https://github.com/pharo-project/pharo-core/commit/7c58b1be0d0f72a2cdbb0f90… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-10-07 (Wed, 07 Oct 2015) Changed paths: R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50368.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50369.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50368.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50369.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50369 16732 DNU when cancel fetch on retrieve icon sets https://pharo.fogbugz.com/f/cases/16732 16577 Random should be in its own package https://pharo.fogbugz.com/f/cases/16577 16726 move Reflectivity-Styling to a separate package https://pharo.fogbugz.com/f/cases/16726 http://files.pharo.org/image/50/50369.zip

Oct. 7, 2015

[ Zn+Zdc ] Implementation of HTTPS proxying using HTTP CONNECT tunneling

by Sven Van Caekenberghe

Hi, Yesterday I did a first implementation of HTTPS proxying using HTTP CONNECT tunneling for Zn+Zdc, this should now be tested by a wider audience. With this new feature it should now be possible to access HTTPS Urls from behind an HTTP proxy. This is for all OS platforms. Thanks Nicolai for finding the spec reference and Torsten for the push. In Zn #bleedingEdge === Name: Zinc-HTTP-SvenVanCaekenberghe.437 Author: SvenVanCaekenberghe Time: 6 October 2015, 9:57:35.790306 pm UUID: 96b9026b-561e-4d6f-88b7-46389b163e99 Ancestors: Zinc-HTTP-SvenVanCaekenberghe.436 Implementation of HTTPS proxying using HTTP CONNECT tunneling https://en.wikipedia.org/wiki/HTTP_tunnel#HTTP_CONNECT_tunneling http://www.ietf.org/rfc/rfc2817.txt (section 5) Rewrite ZnClient>>#newConnectionTo: with delegate to newly added ZnClient>>#setupTLSTo: which implements the mechanism described in the links above Change ZnClient>>#readResponse: not to expect a body with a CONNECT request Change ZnHeaders>>#request: to use #authorityWithPort for the Host header Add ZnNetworkingUtils [class]>>#secureSocketStreamOn: Change ZnRequestLine>>#writeOn: to write the correct Request-URI portion of the Request-Line in case of CONNECT and/or plain HTTP(S) proxying Tested with Squid 3 as proxy === Name: Zinc-Resource-Meta-Core-SvenVanCaekenberghe.54 Author: SvenVanCaekenberghe Time: 6 October 2015, 9:58:39.204572 pm UUID: 134e875c-d2dd-4970-9697-b9d56833d77d Ancestors: Zinc-Resource-Meta-Core-SvenVanCaekenberghe.53 Add ZnUrl>>#authorityWithPort and ZnUrl>>#hasSecureScheme === Name: Zinc-Tests-SvenVanCaekenberghe.234 Author: SvenVanCaekenberghe Time: 6 October 2015, 9:59:59.387302 pm UUID: d2831cd8-fa01-4f44-8533-f5045dabbd7d Ancestors: Zinc-Tests-SvenVanCaekenberghe.233 Modify ZnClientTests>>#testIfFailNonExistingHost because of different behavior when a proxy is involved === On my machine all Zn+Zdc tests succeed with a proxy set (squid 3). Let's hope it works for others too. I did not yet test proxy authorization but I think it should work like before. An HTTP Proxy can be set in World > System > Settings Here is some code to do a simple test ZnClient new get: 'https://s3-eu-west-1.amazonaws.com/public-stfx-eu/test-2050.txt'. ZnClient new get: 'https://s3-eu-west-1.amazonaws.com/public-stfx-eu/small.html'. ZnClient new get: 'http://stfx.eu/small.html'. ZnNetworkingUtils default isProxySet. ZnNetworkingUtils shouldProxyUrl: 'https://s3-eu-west-1.amazonaws.com/public-stfx-eu/small.html' asUrl. Regards, Sven

Oct. 7, 2015

Re: [Pharo-dev] Issue Tracker Choice

by Esteban Lorenzano

Hi, doing our own issue tracker could be cool, but is yet-another-tool-to-maintain (not to take about the development time), so I rather not take that pathâ¦ even if is cool :) yes, having to register is a problem but I simplified the register process (into a one-step process): http://tracker.pharo.org/issues-register-service, so I think this is mitigated (I think the increase of registrations since I made the change is a proof). and FogBugz is proâ¦ even if I dislike the UI a lotâ¦ and I think is too much for usâ¦ and I agree in general that is not the best for an open source project. But we have a tool for free, well maintained and managed. Instead just changing issue tracker I would like to think more in general. For instance, I would like to move the development process to github once we can finish/agree/implement a good way to doit. they it would have a lot of sense use the github issue trackerâ¦ but Iâm not sure it has sense *before*. So there you goâ¦ before thinking on changing the issue tracker I would think which kind of process we want to support and just then think in which issue tracker we need :) Esteban > On 07 Oct 2015, at 09:00, Stephan Eggermont <stephan(a)stack.nl> wrote: > > On 07/10/15 08:27, Eliot Miranda wrote: >> BTW, at ParcPlace we implemented our own. It's not difficult and having something one can tailor is great. Pharo has the relevant web, database & server technology. It would be a great test of the system to implement its own issue tracker. > > http://gsoc2013.esug.org/projects/distributed-issue-tracker > > Stephan > > >

Oct. 7, 2015

Re: [Pharo-dev] Issue Tracker Choice

by Christophe Demarey

Hi Eliot, Le 7 oct. 2015 Ã 08:27, Eliot Miranda a Ã©crit : > >> On Oct 6, 2015, at 8:30 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> Damien Cassou-2 wrote >>> could you please tell us what you don't like about FogBugz >> >> The main thing is that it's not designed for open source projects. Requiring >> account creation before one can even search the open issues is a huge >> barrier. I would guess most new people will hit that wall and give up on >> sending us valuable bug reports. > > > +1. > > BTW, at ParcPlace we implemented our own. It's not difficult and having something one can tailor is great. Pharo has the relevant web, database & server technology. It would be a great test of the system to implement its own issue tracker. Of course it is doable in Pharo but we will NOT go into this direction. We have limited manpower and it is definitely not the place where it will be the more valuable. There are a lot of existing tools / services doing that. Moreover, it will be one more server to maintain... That is also why we want to move slowly to git / gitHub because SmalltalkHub has no added value for us. I would rather say github will offer more services.

Oct. 7, 2015

Re: [Pharo-dev] ARM Cogit

by Esteban Lorenzano

> On 06 Oct 2015, at 23:04, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Alex, > > have you tried building a Cog VM from the Cog svn sources? I expect, provided you hack around the NativeBoost uses, that the VM will work. Android needs also some java crap in the middle (along with an âidle vmâ) to workâ¦ just ARM support is not enough. But there was CogDroid some time ago, kind of hacky but worked and there is JB work who I hope is taken and finished eventually/soon. btwâ¦ my idea is to take JB's approach to âidle vmâ and (once finished) translate it to regular VMâ¦ consuming a constant of 5% cpu is not good at all :( Esteban > > On Tue, Oct 6, 2015 at 12:55 PM, Aliaksei Syrel <alex.syrel(a)gmail.com <mailto:alex.syrel@gmail.com>> wrote: > Hi > > Any news on Pharo VM for android? ;) > > Cheers, > Alex > > On Thu, Apr 23, 2015 at 7:54 AM, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: > This is really excellent! > Keep pushing this. > I'm eager to play with a raspberry. > We should continue to revisit the UI elements to consume less in any case. > Because I'm convinced that we are doing too many things at the wrong place. > > Stef > > Le 22/4/15 21:42, Eliot Miranda a Ã©crit : > > Hi All, > > thanks to hard work by Tim Rowledge and Lars Wasserman we now have a functional JIT for the ARM in the simulator. We're still probably some weeks away from a functional ARM JIT VM; issues like instruction cache flushing on real hardware can be tricky to solve. But we're at least ready to start trying to compile the JIT VM for ARM. Doug, see that I added a build directory for build.linux32ARM/squeak.cog.spur. Hopefully a fast VM for Raspberry Pi and Android is only a few weeks away. > -- > best, > Eliot > > > > > > > -- > _,,,^..^,,,_ > best, Eliot

Oct. 7, 2015

Re: [Pharo-dev] Issue Tracker Choice

by Stephan Eggermont

On 07/10/15 08:27, Eliot Miranda wrote: > BTW, at ParcPlace we implemented our own. It's not difficult and having something one can tailor is great. Pharo has the relevant web, database & server technology. It would be a great test of the system to implement its own issue tracker. http://gsoc2013.esug.org/projects/distributed-issue-tracker Stephan

Oct. 7, 2015

Re: [Pharo-dev] About Magritte Seaside

by Christophe Demarey

Hi Dale, Le 6 oct. 2015 Ã 20:23, Dale Henrichs a Ã©crit : > > > On 10/6/15 5:10 AM, stepharo wrote: >> >> >> Le 6/10/15 11:40, Stephan Eggermont a Ã©crit : >>> On 06-10-15 11:11, stepharo wrote: >>>> I will do a separate configuration of magritte seaside. >>> >>> You need to load the correct groups. Separate configurations are a bad practice and should be eliminated, not encouraged. >> >> I totally disagree. >> And groups are not supported by the configurationBrowser >>> The configuration has a lot of essential complexity, as many different combinations of components are needed in different situations. We need tools that recognize that essential complexity and support it, not tools that try to hide it and then have no practical usability. >> >> Well I disagree. And all the effort of christophe for the new dependencies declarations at the package level just goes in that direction. >> I will do a MagritteSeaside Configuration that I will maintain and I will also do a MagritteTutorial one. >> > Stef, > > I hope you and Christophe are considering cross platform considerations when implementing "new dependencies declarations at the package level" ... MonticelloConfigurations had "package level dependencies" and the implementation was extremely rigid to the point where it wasn't possible to substitute an alternate (platform-speicific) package in the package graph without creating new package versions of all packages in the graph ... Of course I am not aware of the approach that Christophe, but be aware that "there be dragons there":) Thanks for the warning. cross-platform packages are integrated into this new approach by allowing to express dependencies to virtual packages (idea from debian OS: http://www.debian.org/doc/debian-policy/ch-binary.html#s-virtual_pkg) It allows low-coupling and is very flexible. You will find more information in the paper published at IWST'14: https://hal.inria.fr/hal-01086083/document (by the way, you should already have it, I sent it to you last year but you were very busy at this time ;) ) To summarize in a few words, we want dependencies expressed at the package level (and we want more meta-data on packages), we want to decouple a released version of a package from the working copy of the package version description (implies the creation of a package repository + a web interface on top of it to promote/search packages). We also want to detect dependencies automatically as much as possible to avoid missing or not-used dependencies (dependency analyser tool). All together, it will allow to define architectural rules and layers in Pharo. I now experimenting all that with the Pharo bootstrap. If you have any question or remark, do not hesitate to ask or to give feedback. Christophe.

Oct. 7, 2015

Re: [Pharo-dev] Issue Tracker Choice

by Eliot Miranda

> On Oct 6, 2015, at 8:30 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Damien Cassou-2 wrote >> could you please tell us what you don't like about FogBugz > > The main thing is that it's not designed for open source projects. Requiring > account creation before one can even search the open issues is a huge > barrier. I would guess most new people will hit that wall and give up on > sending us valuable bug reports. +1. BTW, at ParcPlace we implemented our own. It's not difficult and having something one can tailor is great. Pharo has the relevant web, database & server technology. It would be a great test of the system to implement its own issue tracker. _,,,^..^,,,_ (phone) > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Issue-Tracker-Choice-tp4854002p4854106.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Oct. 7, 2015