- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [squeak-dev] WebClient httpGet: 'http://freegeoip.net/json/' works on windows not linux

by Tobias Pape

Hi, (cc-ing vm-dev and pharo b/c severity) > On 15.02.2018, at 15:58, Louis LaBrunda <Lou(a)Keystone-Software.com> wrote: > > Hi Levente, > > Thanks for the post. OpenSSL version 1.1.0f is installed. Yes, OpenSSL 1.1 is not yet supported by SqueakSSL. OpenSSL did a major refactoring from 1.0.2 to 1.1.0. Neither the OpenSSL-plugins from before February nor the current ones will work with 1.1. Sorry. As soon as I get roughly 8-10 hours of leisure time, I'm on it. Best regards -Tobias > > Lou > >> On Wed, 14 Feb 2018, Louis LaBrunda wrote: >> >>> Hi Everyone, >>> >>> I use the following: >>> >>> Json readFrom: (ReadStream on: (WebClient httpGet: 'http://freegeoip.net/json/', (WebClient >>> httpGet: 'https://api.ipify.org') content) content utf8ToSqueak). >>> >>> to get latitude and longitude from the internet. It works great on windows but not linux >>> (Raspbian). The #primitiveSSLCreate fails. I expect something linux specific like some FFI or >>> something is missing. Anyone have any idea what? >> >> If it worked on Linux before, then you should use the SqueakSSL plugin >> from an older VM. The code has been changed recently. >> If it never worked before, then you probably don't have openssl 1.0.x >> installed. >> >> Levente >> >>> >>> Lou >>> -- >>> Louis LaBrunda >>> Keystone Software Corp. >>> SkypeMe callto://PhotonDemon >> > -- > Louis LaBrunda > Keystone Software Corp. > SkypeMe callto://PhotonDemon > >

Feb. 15, 2018

[Pharo 7.0-dev] Build #549: 21287-Fix-lint-problems-in-testIndexOfSubCollectionStartingAtIfAbsent

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #549 was: FAILURE. The Pull Request #889 was integrated: "21287-Fix-lint-problems-in-testIndexOfSubCollectionStartingAtIfAbsent" Pull request url: https://github.com/pharo-project/pharo/pull/889 Issue Url: https://pharo.fogbugz.com/f/cases/21287 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 15, 2018

Techtalk Today: Link

by Marcus Denker

Hi, TechTalk today at 17:00 Local European time (in 45 minutes) https://association.pharo.org/event-2797065 <https://association.pharo.org/event-2797065> https://www.youtube.com/c/MarcusDenker/live <https://www.youtube.com/c/MarcusDenker/live> Marcus

Feb. 15, 2018

Re: [Pharo-dev] Searching for an internship

by Maxime Roelandt

if you don't find it i can give u the files 2018-02-15 14:24 GMT+01:00 Maxime Roelandt <mroelandt(a)gmail.com>: > Yes this is on http://www.cincomsmalltalk.com/publicRepository/ > FileOuterNG.html > > I used Steph account to commit > > It is on public cincom store. I think you need VW to connect on (VW 7.8 > it's ok) > > 2018-02-15 12:39 GMT+01:00 phil(a)highoctane.be <phil(a)highoctane.be>: > >> Is FileOuterNG available? >> >> Phil >> >> On Feb 15, 2018 12:06, "Maxime Roelandt" <mroelandt(a)gmail.com> wrote: >> >>> Hi all, >>> >>> I'm searching for an internship as student of Master's 2 degree in >>> Computer Science at University of Lille1. >>> >>> My skills are essentially in Smalltalk and C. >>> >>> Minimum 1500 â¬ net salary. >>> I am available from March : Period 4 to 6 months. >>> >>> I've worked for RMoD team, two times : >>> - 2016 : FileOuterNG -> VisualWorks code converter to Pharo >>> - 2017 : Pillar reengineering. >>> >>> Please find attached my CV if you're interested in >>> >>> ++ >>> >> >

Feb. 15, 2018

Re: [Pharo-dev] Searching for an internship

by Maxime Roelandt

Yes this is on http://www.cincomsmalltalk.com/publicRepository/FileOuterNG.html I used Steph account to commit It is on public cincom store. I think you need VW to connect on (VW 7.8 it's ok) 2018-02-15 12:39 GMT+01:00 phil(a)highoctane.be <phil(a)highoctane.be>: > Is FileOuterNG available? > > Phil > > On Feb 15, 2018 12:06, "Maxime Roelandt" <mroelandt(a)gmail.com> wrote: > >> Hi all, >> >> I'm searching for an internship as student of Master's 2 degree in >> Computer Science at University of Lille1. >> >> My skills are essentially in Smalltalk and C. >> >> Minimum 1500 â¬ net salary. >> I am available from March : Period 4 to 6 months. >> >> I've worked for RMoD team, two times : >> - 2016 : FileOuterNG -> VisualWorks code converter to Pharo >> - 2017 : Pillar reengineering. >> >> Please find attached my CV if you're interested in >> >> ++ >> >

Feb. 15, 2018

[update 6.0] #60532

by Marcus Denker

60532 ----- 20740 isAbstract not working correctly on 64bit https://pharo.fogbugz.com/f/cases/20740

Feb. 15, 2018

[update 6.1] #60531

by Marcus Denker

60531 ----- 20254 Playground should ask to create class for non-Existing Globals https://pharo.fogbugz.com/f/cases/20254 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo60/main/OpalCompiler-Core-TheIntegrat… http://smalltalkhub.com/mc/Pharo/Pharo60/main/Iceberg-Pharo6-TheIntegrator.… http://smalltalkhub.com/mc/Pharo/Pharo60/main/Iceberg-Core-TheIntegrator.1.… http://smalltalkhub.com/mc/Pharo/Pharo60/main/Iceberg-Changes-TheIntegrator… http://smalltalkhub.com/mc/Pharo/Pharo60/main/Iceberg-Adapters-TheIntegrato…

Feb. 15, 2018

Re: [Pharo-dev] OpalCompiler evaluate speed

by monty

That's great, Marcus. Lots of code depends on the compiler for dynamic evaluation, including compilers that translate other languages to ST (like the XPath lib), so a faster compiler isn't insignificant. I know optimizing it takes time and probably isn't a high priority, but we could at least commit to not allowing it to get slower. For example, forget about replacing the RB parser with a PP-based one (which some have expressed interest in), since it looks like it would be slower, even with PP compiler: http://scg.unibe.ch/research/petitcompiler > Sent: Tuesday, February 13, 2018 at 12:04 PM > From: "Marcus Denker" <marcus.denker(a)inria.fr> > To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Subject: Re: [Pharo-dev] OpalCompiler evaluate speed > > > > > On 24 Nov 2017, at 10:54, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > > > > > >> On 23 Nov 2017, at 23:37, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > >> > >> Hi Nicolas. > >> > >> Just some comments: > >> > >> Another thing you can try is to remove the allocation of Opal's IR. It seems people use the IR only through the IRBuilder, so the API can be kept but it can generate directly bytecode instead of IR then bytecode. Removing those allocations would speed things up. It means merging IRFix / IRTranslator / IRBytecodeGenerator somehow and have the IRBuilder API directly call the new resulting merged class. > >> > >> Another thing is that when Opal became the default compiler, I evaluated the speed and saw it was slower, but when loading large projects it seemed loading time was dominated by Monticello / source reading / source loading and the compilation time was overall not that significant (< 20% of time). I don't know if this is still the case with GIT. I have problems currently when editing some large methods (it seems in the IDE the method is compiled at each keystroke...) and when doing OpalCompiler recompileAll (which I do often since I edit bytecode sets) but else the performance of Opal seems to be OK. Evaluate performance may be relevant in some cases but I've never found such cases outside of the IDE in production. > >> > > > (old mailâ¦ late answer). > > In the meantime we found out that #recompileAll was recompiling meta-classes twice, with that fixed rempiling is a little bit faster (from around one minute to 50 seconds on my machine). > > > > One other thing that needs cleanup: the API/ OpalCompiler class. This tries to be compatible with the old API (e.g. failBlock) and got quite hacked to death over > > timeâ¦ we should clean that up. The complexity of #evaluate is partly due to that, I think. > > > > As a first step, I changed #evaluate to not store sources in the trailer, this means that we do not pretty-print the source anymore. > > https://github.com/pharo-project/pharo/pull/880 > > The only downside is that a (not very practically relevant) test failed (#testSourceNodeOptimizedBlock). I think we can ignore that for now and fix it when it turns out to be > a problem (the test works fine when rewritten to compile a full method). > > Marcus > > > >

Feb. 15, 2018

Re: [Pharo-dev] Pavel's ChangeLog week of 2018-02-05

by Marcus Denker

> On 15 Feb 2018, at 12:56, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > 2018-02-15 11:31 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: >> >> >>> On 14 Feb 2018, at 21:34, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >>> >>> Le 14/02/2018 Ã 20:19, Stephane Ducasse a Ã©crit : >>>> Thanks Pavel this looks quite fast :). >>>> Do you have a scenario in mind that could take advantage of this? >>> >>> I'd be very interested to see that used with image segments for objects migration between images running in different processes (or coupled with a distributed shared memory implementation like [1]). >>> >>> If latency is low enough, I think multi-window applications could be developped as multi-process single window images (and we could get scalability to thousands of cores, if the application design is right. Even code synchronisation between images would be easy to do). >>> >>> >> Yes, that is the direction to explore :-) > > When I worked on that sort of systems, one of the questions I had was: > what about the GC ? But yes, in today's context, focusing on process > based concurrency can be interesting. > >> This started with me and Pavel discussion about the general idea that it would be interesting if Objects would actually be âreally recursiveâ (and the whole system would be such an Object, too). > > I'm not sure I get the concept. Would you be ready to explain ? I have started to write something about it (I need to make it clearer for myself, too). When it is in some presentable shape (currently just notes) I will forward it. Marcus

Feb. 15, 2018

Re: [Pharo-dev] Pavel's ChangeLog week of 2018-02-05

by Thierry Goubier

2018-02-15 11:31 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > > >> On 14 Feb 2018, at 21:34, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >> >> Le 14/02/2018 Ã 20:19, Stephane Ducasse a Ã©crit : >>> Thanks Pavel this looks quite fast :). >>> Do you have a scenario in mind that could take advantage of this? >> >> I'd be very interested to see that used with image segments for objects migration between images running in different processes (or coupled with a distributed shared memory implementation like [1]). >> >> If latency is low enough, I think multi-window applications could be developped as multi-process single window images (and we could get scalability to thousands of cores, if the application design is right. Even code synchronisation between images would be easy to do). >> >> > Yes, that is the direction to explore :-) When I worked on that sort of systems, one of the questions I had was: what about the GC ? But yes, in today's context, focusing on process based concurrency can be interesting. > This started with me and Pavel discussion about the general idea that it would be interesting if Objects would actually be âreally recursiveâ (and the whole system would be such an Object, too). I'm not sure I get the concept. Would you be ready to explain ? > And then asking the question: what is the minimal thing we need to explore that direction? On a meta-level, I can understand that. Thierry >> >> [1] https://hal.archives-ouvertes.fr/hal-01679052 >> > > I will read that. I talked to Loic about that sort of ideas (his S-DSM could do even more interesting things) but also of the fact we don't have the resources and time to explore it :( Thierry > > Marcus > >

Feb. 15, 2018