- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Moose-dev] [ann] bloc & cairo+morphic

by philippe.back＠highoctane.be

Definitely great! It is nice to see feenk getting more Pharo solid engineering super powers. Phil Le 8 mai 2017 23:00, "Tudor Girba" <tudor(a)tudorgirba.com> a Ã©crit : > Hi, > > We are happy to announce that based on the work of Glenn, Alex extended > Bloc (Sparta) to work directly in the Morphic world using Cairo as a > backend. > > Cairo is less powerful than Moz2D (see the screenshot below for an > example), but the implementation addresses a concern that the community > raised regarding a perceived increased liability due to the dependency to > Moz2D. Essentially this means that Bloc can be treated as another graphical > library that can coexist with Morphic without requiring any external VM > plugin. > > > I would also like to point out that adding a new backend and host was > possible because of the many iterations (including throwing away whole > implementations) that Alex and Glenn went through. I think they did an > amazing job. > > You can find a bit more details about Bloc here: > http://www.humane-assessment.com/blog/bloc-flexible-backends-hosts/ > > Another issue raised regarding Bloc was that of the engineering effort > required to make it a reality. That is why I would also like to announce > that Alex joined feenk.com where he is primarily working on the graphical > stack for Pharo. > > Cheers, > Doru > > > -- > www.tudorgirba.com > www.feenk.com > > "To lead is not to demand things, it is to make them happen." > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > >

May 9, 2017

Re: [Pharo-dev] [ann] bloc & cairo+morphic

by Ignacio Sniechowski

Doru, This is great news! Thanks for sharing. Cheers Nacho *Lic. Ignacio Sniechowski, MBA* *Prosavic SRL* â* (5411) 4542-6712* ð±* (54911) 6749-4721* On Mon, May 8, 2017 at 6:00 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > We are happy to announce that based on the work of Glenn, Alex extended > Bloc (Sparta) to work directly in the Morphic world using Cairo as a > backend. > > Cairo is less powerful than Moz2D (see the screenshot below for an > example), but the implementation addresses a concern that the community > raised regarding a perceived increased liability due to the dependency to > Moz2D. Essentially this means that Bloc can be treated as another graphical > library that can coexist with Morphic without requiring any external VM > plugin. > > > I would also like to point out that adding a new backend and host was > possible because of the many iterations (including throwing away whole > implementations) that Alex and Glenn went through. I think they did an > amazing job. > > You can find a bit more details about Bloc here: > http://www.humane-assessment.com/blog/bloc-flexible-backends-hosts/ > > Another issue raised regarding Bloc was that of the engineering effort > required to make it a reality. That is why I would also like to announce > that Alex joined feenk.com where he is primarily working on the graphical > stack for Pharo. > > Cheers, > Doru > > > -- > www.tudorgirba.com > www.feenk.com > > "To lead is not to demand things, it is to make them happen." > > > > >

May 8, 2017

[ann] bloc & cairo+morphic

by Tudor Girba

Hi, We are happy to announce that based on the work of Glenn, Alex extended Bloc (Sparta) to work directly in the Morphic world using Cairo as a backend. Cairo is less powerful than Moz2D (see the screenshot below for an example), but the implementation addresses a concern that the community raised regarding a perceived increased liability due to the dependency to Moz2D. Essentially this means that Bloc can be treated as another graphical library that can coexist with Morphic without requiring any external VM plugin. I would also like to point out that adding a new backend and host was possible because of the many iterations (including throwing away whole implementations) that Alex and Glenn went through. I think they did an amazing job. You can find a bit more details about Bloc here: http://www.humane-assessment.com/blog/bloc-flexible-backends-hosts/ Another issue raised regarding Bloc was that of the engineering effort required to make it a reality. That is why I would also like to announce that Alex joined feenk.com where he is primarily working on the graphical stack for Pharo. Cheers, Doru -- www.tudorgirba.com www.feenk.com "To lead is not to demand things, it is to make them happen."

May 8, 2017

Adding class side inst.var to a class using Trait results in nil message sent

by Aliaksei Syrel

Hi, Screenshot tells everything :) I was trying to add "asdasd" inst var [image: Inline images 1] Cheers, Alex

May 8, 2017

(Iceberg?) Merge compiles copies of trait methods in user classes

by Aliaksei Syrel

Hi, Time to time I notice that suddenly Trait methods are copied to user classes. And now I realised that this happens as the result of merge even if there are no differences in that particular Trait. Sometimes I manage to notice new methods in changes window but sometimes not, and then after months it is extremely difficult to find bugs related to copied methods, because I may change Trait code expecting that it will be updated in all users of that trait... Unfortunately I don't have a testcase that reproduces this issue.. sorry.. Just wanted to let you know, maybe it is something that can be fixed before release... Cheers, Alex

May 8, 2017

FileReference>>=

by Alistair Grant

Hi All, The current definition of FileReference>>= returns false if two instances point to the same location, but one is relative and the other is absolute, e.g.: | f1 f2 | f1 := FileLocator workingDirectory / 'pharo-local'. f2 := f1 asAbsolute. f1 = f2 "false" This definition seems unintuitive to me as I'd expect this to be true since they are both pointing to the same file/directory. This introduces unexpected behaviour, e.g. I currently have two entries in Iceberg pointing to the same local git repository as one was added with a relative file reference, while the other was added with an absolute file reference. Apart from the potential to introduce problems by changing the definition, are there any arguments in favour of keeping the current definition? What do you think of changing the definition (in Pharo 7)? P.S. If we decide not to change it, then IceRepository>>checkForRegistryConflicts should be modified to compare absolute paths. Thanks, Alistair

May 8, 2017

Re: [Pharo-dev] Anyone meeting up night before Pharo Days (17th?)

by Tim Mackinnon

It sounds like there will at least be a few of us around wanting a beer - so maybe we can pick a venue and agree to meet up? I think it will be too late for me to eat (so Iâll have something on the train), but it would be nice to share a few beers and get caught up with whatâs what, in preparation for Thurs. Tim > On 7 May 2017, at 18:59, Stephan Eggermont <stephan(a)stack.nl> wrote: > > On 06/05/17 12:58, Tim Mackinnon wrote: >> Hi guys - I managed to get a âweeknight passâ so that I can come to >> Pharo days and try and catch up with all the progress you have made. >> >> Iâm taking a Eurostar on Wed night (17th) and wondering if anyone is >> meeting up the night before on the 17th? I donât arrive until 8:30 - >> but maybe some of you are having some post supper drinks somewhere? > > Yes, good idea. I'll arrive with a TGV from CDG at 21:11 > >> I have booked a hotel near the venue, but Iâm thinking that I may >> change it, to somewhere in town as I think it might make more sense >> as Iâm sure folks may end up eating in town anyway. > > I haven't booked a hotel yet. I'll go for in-town. > > Stephan > > > > >

May 8, 2017

Re: [Pharo-dev] Iceberg

by Esteban Lorenzano

> On 8 May 2017, at 02:43, Ben Coman <btc(a)openInWorld.com> wrote: > > Until recently to work around a bug people were directed to "latest" vm. > Now we are back to "stable"... http://files.pharo.org/vm/pharo-spur32/ <http://files.pharo.org/vm/pharo-spur32/> yes. and please, peopleâ¦ note that using âstableâ should be the regular way. we were using latest because we are so unstable that we needed to (and I cannot ensure we will not have other periods like that). But in general, users not trying to fix something on the edge, need to stay with the stable. cheers! Esteban > > cheers -ben > > On Mon, May 8, 2017 at 2:32 AM, Myroslava Romaniuk <romaniuk(a)ucu.edu.ua> wrote: >> Which one is the stable VM then? >> >> On 7 May 2017 21:07, "Esteban Lorenzano" <estebanlm(a)gmail.com> wrote: >>> >>> are you trying VM latest? >>> because you should use the stable now :) >>> >>> I explain: I updated the latest VM to libgit2 0.25.1. While this works on >>> most of my cases, I spotted this problem too. >>> >>> cheers, >>> Esteban >>> >>> On 7 May 2017, at 18:40, Myroslava Romaniuk <romaniuk(a)ucu.edu.ua> wrote: >>> >>> I am also trying to clone a repository and for me the command causes the >>> following error: LGit_GIT_ERROR: error authenticating: failed connecting >>> agent. I am using the latest image (60482) on Win 7 (64 bit). >>> >>> On 7 May 2017 at 19:06, Elhamer <abdelkhalekdev(a)gmail.com> wrote: >>>> >>>> EstebanLM wrote >>>>>> Yes, there is a bug now in iceberg (I will fix it soon), for now you >>>>>> can >>>> go with: >>>>> >>>>>> IceRepository defaultBackendType: #IceLibgitLocalRepository. >>>> >>>> >>>> This actually causes an Assertion failure, then a total crash: >>>> --------------------------- >>>> Microsoft Visual C++ Runtime Library >>>> --------------------------- >>>> Assertion failed! >>>> >>>> Program: ... >>>> File: e:/workspace/PharoVM-spur32/Architecture.../remote.c >>>> Line: 430 >>>> >>>> Expression: out && repo && name >>>> >>>> For information on how your program can cause an assertion >>>> failure, see the Visual C++ documentation on asserts >>>> >>>> (Press Retry to debug the application - JIT must be enabled) >>>> --------------------------- >>>> Abort Retry Ignore >>>> --------------------------- >>>> >>>> I am using the image #60480 on a Windows 10 64bits OS >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> View this message in context: >>>> http://forum.world.st/Iceberg-tp4945776p4945804.html >>>> Sent from the Pharo Smalltalk Developers mailing list archive at >>>> Nabble.com. >>>> >>> >>> >>> >>> -- >>> Ð Ð¿Ð¾Ð²Ð°Ð³Ð¾Ñ, >>> ÐÐ¸ÑÐ¾ÑÐ»Ð°Ð²Ð° Ð Ð¾Ð¼Ð°Ð½ÑÐº. >>> >>> >> >

May 8, 2017

Estebanâs list of blocking issues for release Pharo 6.0 (updated to May 08)

by Esteban Lorenzano

Hello, This are the things I believe still needs to be solved to be able to release Pharo 6.0: PENDING: - image: iceberg hit the image (dev-0.4 is ready to enter) - remove all test regressions - NEW: pharovm is crashing on 64bits FIXED: (none) POSPOSED: iceberg to use libgit2 0.25.1 (needed to compile it in 64bits, but not mandatory) Release checklist: ==== - Prepare release notes Image: - add welcome browser (ONGOING) - generate PharoV60.sources (ONGOING) - move SystemVersion - prepare new ScriptLoader70 package (in theory, this will not needed anymore but better to have it as a backup :P) VM: - stable for 6.0 release (DONE) WebSite: - Update index - Update download page Infrastructure: - ZeroConf: Open new 7.0 development (ONGOING) - SmalltalkCI: Open new 7.0 development (ONGOING) - Create platform stable versions - Jenkins: move all CI projects to Pharo 7.0 (ONGOING) Pub: - announce post - announce mail - post to YC, Reddit Iâm targeting this week for release. But you know how it isâ¦ it will happen most probably next monday ;) Also, I donât know what the problem with 64bits crashing is, Iâm just starting to explore thereâ¦ that can be a detail or a huge problem, and dince 64bits is âTHEâ important part of this release, is blocking enough to delay release.

May 8, 2017

Esteban's ChangeLog week of 1 May 2017

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 1 May 2017 to 7 May 2017. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=1/5/2017&to=7/5/2017 ChangeLog ========= 5 May 2017: ----------- * I just made this little script: ---- startDate := Date year: 2016 month: 04 day: 01. authors := Set new. unknown := Set new. CompiledMethod allInstancesDo: [ :each | | array date | array := each timeStamp substrings. ((array size = 3) and: [ date := [ array second asDate ] on: Error do: [ :e | ]. date notNil ]) ifTrue: [ date >= startDate ifTrue: [ authors add: array first trimBoth ] ] ifFalse: [ unknown add: each timeStamp] ]. ---- To collect this release authors :) Seems that we have at least 88 contributors this version. And we are not counting VM contributors or the people who contributes in other ways: documenting, enhancing frameworks... just particupanting in the lists. This are the authors this script collects: [[[ a Set('BernhardPieber' 'AliakseiSyrel' 'MaxLeske' 'StephanEggermont' 'KenCausey' 'RogerStebler' 'EliotMiranda' 'AndreiChis' 'SergeStinckwich' 'DenisKudryashov' 'ThierryGoubier' 'CyrilFerlciot' 'HenrikSperreJohansen' 'ThibaultRaffaillac' 'monty' 'MarcusDenker' 'RonieSalgado' 'Uko' 'ChristopheDemarey' 'NicolaiHess' 'JohnSnow' 'SomeName' 'md' 'DenisKUdryashov' 'StefanReichhart' 'BenComan' 'DirkRoeleveld' 'johanfabry' 'AutoDeprecationRefactoring' 'CyrilFerlicot' 'YuriyTymchuk' 'mml' 'GitHub' 'SvenVanCaekenberghe' 'LucFabresse' 'matteob8' 'JurajKubelka' 'TommasoDalSasso' 'VincentBlondeauMaximeRoelandt' 'kks' 'pk' 'RM' 'AlexandreBergel' 'auto' 'MerwanOuddane' 'PavelKrivanek' 'OffrayLuna' 'dik' 'nice' 'BooleanSlotTest' 'StephaneDucasse' 'LionelAkue' 'VincentBlondeau' 'eem' 'HenrikNergaard' 'AlejandroInfante' 'hn' 'NicoPasserini' 'PropertySlotTest' 'HilaireFernandes' 'PeterUhnak' 'BernardoContreras' 'ClementBera' 'PabloTesone' 'UnlimitedInstanceVariableSlotTest' 'ThibaultArloing' 'CamilloBruni' 'Spirita' 'cb' 'Anonymous' 'TorstenBergmann' 'PaulDeBruicker' 'TheIntegrator' 'ClementBer' 'AlistairGrant' 'TravisCI' 'JanVanDeSandt' 'TudorGirba' 'EstebanLorenzano' 'SlotErrorsTest' 'Denis' 'ClementBEra' 'MartinDias' 'GlennCavarle' 'GustavoSantos' 'GuillermoPolito' 'RyckewaertValentin' 'ValentinRyckewaert') ]]] Yes, there are some repeated (like "Denis" and "DenisKudriasov") and some wrong (like "CamilloBruni", he is not in the community since some time now), and finally there are others that are robots (like "TheIntegrator"). But this gives a hint of the people contributing which overall will be more than 80 for sure. 4 May 2017: ----------- * So, I worked a bit on [smalltalk-travis-ci](http://github.com/estebanlm/smalltalk-travis-ci) to allow some environment configurations: ---- PHARO_VM=stable*|latest PHARO_ARCH=i386*|x86_64 LINUX_HEARTBEAT=threaded*|itimer ---- Idea is simple: we want to be able to tune the compilations a bit more than now. The options added allows us to declare the type of VM (and in the case of the +PHARO_ARCH+ variable, also the type of the image). For now, this is experimental and if you want access to it you need to add this to your +.travis.yml+ file: ---- smalltalk_edge: source: estebanlm/smalltalk-travis-ci branch: dev ---- I will test and add other options as we need, but it remains to integrate it/generalise it better, that needs to be talked with Fabio later :) * I just fixed all crashes on [libgi2 0.25.1](https://github.com/pharo-vcs/libgit2-pharo-bindings/tree/v0.25.1) and [iceberg](https://github.com/pharo-vcs/iceberg) ! But now I realised I cannot activate the tests on github and travis because it needs a special VM :S 3 May 2017: ----------- * I spent the day recovering the tests for [iceberg](http://github.com/pharo-vcs/iceberg). At this moment, tests are disabled because after moving to internal backend they got broken. Now, we need to make then pass. And I 'almost' succeeded. They are still two tests crashing the image, but most of the rest seems to be ok. I hope to finish tomorrow. * I take some time to verify and promote new [stable VMs for Pharo 6.0](http://files.pharo.org/get-files/60). They are now based on the [opensmalltalk-vm](http://github.com/opensmalltalk/opensmalltalk-vm) process so I expect certain noise, but in general this should be working a lot better than before. cheers! Esteban

May 8, 2017