- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Pharo-users] Happy new year 2016

by philippe.back＠highoctane.be

Happy New Year to the Community that makes the tool with the shortest path between the brain and actual tangible executable results. I am appreciating it even more now that I have to work with toolchains requiring lengthy compilation. How primitive. Let's make 2016 a great Pharo year. And see you at PharoDays! Phil On Jan 1, 2016 7:55 PM, "Trussardi Dario Romano" <dario.trussardi(a)tiscali.it> wrote: > > > > Happy new year to all! > > + 1000 > > > > > Alexandre > > > > > >> On Jan 1, 2016, at 12:57 PM, stepharo <stepharo(a)free.fr> wrote: > >> > >> Hi Pharoers > >> > >> I want to thank all of you for making Pharo what it is becoming: a Really Cool system and community. > >> > >> I wish you good health and a lot of business or fun in Pharo :). > >> > >> 2016 will see many changes that are planned > >> to name a few > >> - Pharo 5.0 with Spur > >> - Pharo 5.0 with 64 bits > >> - Bootstrap Pharo in production > >> - SDL full integration > >> - Git and Package validation > >> - A full Mooc on Pharo > >> - A couple of cool tutorials > >> And I'm sure many unexpected project and libraries... > >> > >> The consortium should continue to grow so if you are hesitating to join please do. > >> > >> Stef > >> > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > >

Jan. 1, 2016

Re: [Pharo-dev] [Pharo-users] Happy new year 2016

by Trussardi Dario Romano

> Happy new year to all! + 1000 > > Alexandre > > >> On Jan 1, 2016, at 12:57 PM, stepharo <stepharo(a)free.fr> wrote: >> >> Hi Pharoers >> >> I want to thank all of you for making Pharo what it is becoming: a Really Cool system and community. >> >> I wish you good health and a lot of business or fun in Pharo :). >> >> 2016 will see many changes that are planned >> to name a few >> - Pharo 5.0 with Spur >> - Pharo 5.0 with 64 bits >> - Bootstrap Pharo in production >> - SDL full integration >> - Git and Package validation >> - A full Mooc on Pharo >> - A couple of cool tutorials >> And I'm sure many unexpected project and libraries... >> >> The consortium should continue to grow so if you are hesitating to join please do. >> >> Stef >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

Jan. 1, 2016

Re: [Pharo-dev] [Pharo-users] Happy new year 2016

by Dimitris Chloupis

Happy new year Stef, I wish hapiness , creativity and health to you , your family and all Pharoers I am interesting to learn more about : - SDL full integration Package validation what those mean exactly ? thanks for keep making pharo more awesome :) On Fri, Jan 1, 2016 at 6:56 PM Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Happy new year to all! > > Alexandre > > > > On Jan 1, 2016, at 12:57 PM, stepharo <stepharo(a)free.fr> wrote: > > > > Hi Pharoers > > > > I want to thank all of you for making Pharo what it is becoming: a > Really Cool system and community. > > > > I wish you good health and a lot of business or fun in Pharo :). > > > > 2016 will see many changes that are planned > > to name a few > > - Pharo 5.0 with Spur > > - Pharo 5.0 with 64 bits > > - Bootstrap Pharo in production > > - SDL full integration > > - Git and Package validation > > - A full Mooc on Pharo > > - A couple of cool tutorials > > And I'm sure many unexpected project and libraries... > > > > The consortium should continue to grow so if you are hesitating to join > please do. > > > > Stef > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

Jan. 1, 2016

Re: [Pharo-dev] [Pharo-users] Happy new year 2016

by Alexandre Bergel

Happy new year to all! Alexandre > On Jan 1, 2016, at 12:57 PM, stepharo <stepharo(a)free.fr> wrote: > > Hi Pharoers > > I want to thank all of you for making Pharo what it is becoming: a Really Cool system and community. > > I wish you good health and a lot of business or fun in Pharo :). > > 2016 will see many changes that are planned > to name a few > - Pharo 5.0 with Spur > - Pharo 5.0 with 64 bits > - Bootstrap Pharo in production > - SDL full integration > - Git and Package validation > - A full Mooc on Pharo > - A couple of cool tutorials > And I'm sure many unexpected project and libraries... > > The consortium should continue to grow so if you are hesitating to join please do. > > Stef > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 1, 2016

Happy new year 2016

by stepharo

Hi Pharoers I want to thank all of you for making Pharo what it is becoming: a Really Cool system and community. I wish you good health and a lot of business or fun in Pharo :). 2016 will see many changes that are planned to name a few - Pharo 5.0 with Spur - Pharo 5.0 with 64 bits - Bootstrap Pharo in production - SDL full integration - Git and Package validation - A full Mooc on Pharo - A couple of cool tutorials And I'm sure many unexpected project and libraries... The consortium should continue to grow so if you are hesitating to join please do. Stef

Jan. 1, 2016

Re: [Pharo-dev] Some GT tool for this?

by stepharo

Andrei / Mariano could you package them as extension of MC and we can integrate them in Pharo. Stef Le 11/12/15 20:01, Andrei Chis a Ã©crit : > You can add the two methods below. Then when you open Spotter on a > package you can also search through it's history. > This will trigger an update if the history is not present, but Spotter > will still respond quite fast. > > You can also dive in a MCVersionInfo to see its ancestors. > > RPackage>>spotterHistoryFor: aStep > <spotterOrder: 100> > aStep listProcessor > title: 'History'; > allCandidates: [ |ancestry| > ancestry := (MCWorkingCopy allManagers detect: [:each | each > packageName = self name]) ancestry. > ancestry withBreadthFirstAncestors select: [:each | each isKindOf: > MCVersionInfo] ]; > candidatesLimit: 50; > itemName: [ :each | each name, ' - ', each message ]; > filter: GTFilterSubstrings > > MCVersionInfo>>spotterPreviewCodeIn: aComposite > <spotterPreview: 10> > aComposite text > title: 'Summary'; > display: [ > self summaryHeader, String cr, > 'Message:', String cr, self message ]; > entity: self. > Cheers, > Andrei > > > > On Fri, Dec 11, 2015 at 4:52 PM, Eliot Miranda > <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: > > Hi Mariano, > > for this in Squeak I added a simple menu pick to the > Monticello Browser's package list menu called "search history" > which opens up a workspace containing the entire history as a flat > string. I then just search using ctrl-f. You can find it in a > current squeak trunk image. > > _,,,^..^,,,_ (phone) > > On Dec 10, 2015, at 9:12 AM, Mariano Martinez Peck > <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: > >> How many times have you tried to search a string as a comment of >> a commit in all the history? Myself: many many times. I know we >> need much better tools for that, store the history in a another >> way, provide a nicer API, etc etc. And I know there were topics >> about that. >> >> However, I would deeply appreciate a very short term solution for >> ease that. The model side is as simple as this: >> >> | packageName ancestry anscestors substring | >> packageName := 'MyPackageXX'. >> substring := 'whatever I want to search'. >> ancestry := (MCWorkingCopy allManagers detect: [:each | each >> packageName = packageName] ) ancestry. >> anscestors := ancestry withBreadthFirstAncestors select: [:each | >> each isKindOf: MCVersionInfo]. >> anscestors select: [ :each | each message includesSubstring: >> substring ] >> >> Do you think it's worth a simple UI tool? Custom inspector of >> MCAncestry? >> >> Cheers, >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com > >

Jan. 1, 2016

Re: [Pharo-dev] Preview of new FFI?

by stepharo

thanks mariano Esteban may be some of the points are worth - documenting - or introducing the NB behavior. Stef Le 29/12/15 00:43, Mariano Martinez Peck a Ã©crit : > > > On Wed, Dec 23, 2015 at 10:30 AM, Torsten Bergmann <astares(a)gmx.de > <mailto:astares@gmx.de>> wrote: > > I guess Esteban is busy as he is with Stef in Togo. I started > porting to > new FFI initial stuff and chatted with Esteban on Slack. > > When you use the latest Pharo 5 image (together with the spur VM) you > have the new FFI right inside. Athens is running already on the > new FFI. > > NB is still not unloaded - but it will be unloaded soon. The idea > is that > people can recover what they need afterwards. For some cases it > should be > straightforward to convert. > > A short summary of my findings: > > - check the "FFI-NB" package in recent Pharo 5 images like Pharo > 5 #50510 as of today > The name is misleading - it is not the NativeBoost but the new FFI > - check the new classes in this package that are prefixed with > "FFI" like > FFIExternalObject (replacement for NBExternalObject), > FFIExternalStructure > (replacement for NBExternalStructure), ... > - If you generate fields from a struct the accessors are not > generated > into non-package "*generated-code-non-existing-package" but are > now generated into > method category "accessing structure variables" and will > therefore be part of your > MCZ code package > - #nbCall: and #nbCall:module: work for compatibility, I guess we > should add a deprecation > to them > - it is better to use ffiCall:, ffiCall:module: now > - there is no need to have a pragma with NativeBoostPlugin > anymore, at least it > worked for me without it just by using #ffiCall: ... > - there is a new repo: http://smalltalkhub.com/#!/~Pharo/FFI-NB > <http://smalltalkhub.com/#%21/%7EPharo/FFI-NB> since last week, > but I guess the code in the image is more recent > > > Besides the list mentioned by Torsten, these are the ones I found out: > > - You now need #ffiLibraryName rather than #nbLibraryNameOrHandle > - The #free you should send when you manually #allocate: now clears > (put all zeros) in the handle. That means, you must free AFTER having > read the value (like getting the handle integer) and kept it. With NB, > the #free would only free the external side but would keep the > internal value in the handle. That was handy because you could free > the resources in one level, pass around the pointer, and get the > number later. > - Previously, a FFI call to a function that answered an opaque > (FFIExternalObject subclass) as return value, AND the answer was a > NULL, then NB would answer nil to the FFI call rather than > a FFIExternalObject subclass instance. Now, it answers a instance of > the FFIExternalObject subclass, which answers true to #isNull. > - Previously you could #allocate: and get a NBExternalAddress (a > pointer) which could be passed around to a FFI call whose type in the > FFI call signature was itself a NBExternalAddress. Right now it seems > the new FFI signature must be specified with "void*" ?? > > Problems I've experienced so far while trying to port my > OS-Windows project: > - FIICallout does not understand #optionAt:, no support for > options like #WinUnicode so far > - FFIExternalType sizeOf: #ulong failed > > > > Yes, I would appreciate this too. I really need a "NBExternalType > sizeOf: #ulong" so that we can easy the future transition to 64 bits. > Right now I am hardcoding stuff ;) > > - the spur VM for Windows does not include all latest fixes for > Windows VM, like > CTRL keys (https://pharo.fogbugz.com/f/cases/17289) > > Hope this helps a little bit until some more bugs are sorted out/a > more detailed info > for conversion is available. > > Bye > T. > > Gesendet: Mittwoch, 23. Dezember 2015 um 13:55 Uhr > Von: "Mariano Martinez Peck" <marianopeck(a)gmail.com > <mailto:marianopeck@gmail.com>> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org > <mailto:pharo-dev@lists.pharo.org>> > Betreff: Re: [Pharo-dev] Preview of new FFI? > > We are in the same boat. Even worst, I suspect I am using some > parts of ASMJIT which I guess won't be in new FFI, so I have on > clue how I would make that parts to work.... > > On Wed, Dec 23, 2015 at 9:16 AM, Pierce Ng <pierce(a)samadhiweb.com > <mailto:pierce@samadhiweb.com>> wrote:Hi, > > (For Esteban perhaps...) > > Is there an image/VM combo to preview the new FFI? I just made > NBSQLite3 work > with SQLcipher (for transparent database encryption) but don't > want to spend > any effort refactoring if I need to redo for the new FFI. > > Pierce > > -- > Mariano > http://marianopeck.wordpress.com[http://marianopeck.wordpress.com] > > > > > -- > Mariano > http://marianopeck.wordpress.com

Jan. 1, 2016

Re: [Pharo-dev] About loading PetitParser into Pharo 5?

by Stephan Eggermont

On 31/12/15 10:25, H. Hirzel wrote: > Hello > > PetitParser (in Catalog) does not load yet in Pharo 5. It is tagged > with 'Pharo 4'. > > The feedback message is that the installation was aborted. > > Where can I check why it has been aborted? Hi Hannes, I copied a newer version of the configuration to the Pharo4 and 5 metarepos. The last one there was 61 from March 16. Stephan

Dec. 31, 2015

Re: [Pharo-dev] [Moose-dev] Roassal2 in Pharo 5 -> segfault

by Nicolai Hess

2015-12-31 10:09 GMT+01:00 stepharo <stepharo(a)free.fr>: > Hi nicolai > > > The same on windows. Every RoassalExample crashes immeditly. >> Simple Trachel examples are working (TRCanvasExample>>circle) >> but as soon as some text is drawn (TRCanvasExample>>label) >> the vm crashes. >> >> For example, in >> CairoFreeTypeFontRenderer>>#glyphsOf: aString from: start to: end >> at: >> self freeGlyphs: ptr. >> >> If I remove this line, or replace it with >> ptr free. >> The VM crashes at some >> primitiveFFIAllocate call >> >> But I don't understand the whole implementation behind the new FFI (don't >> understand what are the difference between #getHandle, #pointer, >> #gcpointer, ... what memory >> is garbage collected,. what not or when the memory should be freed by >> cairos api (like void cairo_glyph_free (void *glyphs)). >> > Thanks for asking. > Esteban should document all that. > I think that we need more people looking at it and pushing the > documentation. > I don't understand why this is working on Linux, but not on windows. Any hints where the FFI implementation depends on differences between windows and linux? > > Stef > >

Dec. 31, 2015

Re: [Pharo-dev] [Moose-dev] Roassal2 in Pharo 5 -> segfault

by Alexandre Bergel

ok cool! Alexandre > On Dec 31, 2015, at 6:10 AM, stepharo <stepharo(a)free.fr> wrote: > > > > Le 30/12/15 19:03, Alexandre Bergel a Ã©crit : >> Esteban, do you have a bit of documentation? > > it is on the way. Esteban started to sketch an online when we were in Togo and I think that FFI will be the > item number one of Esteban for the coming weeks. > > stef >> The OpenGL bindings will have to be migrated. It would be great to have a starting point. >> >> Cheers, >> Alexandre >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >>> On Dec 30, 2015, at 7:51 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> Hi, >>> >>> Iâve seen this aroundâ¦ I think is because a problem copying memoryâ¦ I will check it (next week, Iâm on holidays now) but I would like to have a bug report, please. >>> >>> btwâ¦ the crashes are not related to Spur but the new FFI implementation (and the migration from old NativeBoost). Spur itself is pretty stable :) >>> >>> Esteban >>> >>>> On 29 Dec 2015, at 19:59, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>>> >>>> I have also seen some random crashes using Spurâ¦ >>>> >>>> Alexandre >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>>> On Dec 29, 2015, at 2:33 PM, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: >>>>> >>>>> Hi all, >>>>> >>>>> just in case this is not a known bug: Intensive use of Roassal2 in Pharo 5 causes a segfault of the mac vm. A crash.dump is attached. Itâs the vm I got just now ( wget --quiet -O - get.pharo.org/50+vm | bash ) and Pharo5 with Alexesâ 17280 slice to make Roassal visualize shapes correctly. >>>>> >>>>> To reproduce, all I need to do is have a visualization open with a layout animation and after some time it will crash. I use this in LRP and I can give easy steps to reproduce if needed. >>>>> >>>>> <crash.dmp> >>>>> >>>>> ---> Save our in-boxes! http://emailcharter.org <--- >>>>> >>>>> Johan Fabry - http://pleiad.cl/~jfabry >>>>> PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev(a)list.inf.unibe.ch >>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)list.inf.unibe.ch >>> https://www.list.inf.unibe.ch/listinfo/moose-dev >> > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 31, 2015