- Pharo-dev - lists.pharo.org

how to make a method inlined

by Ben Coman

Since DelayScheduler runs very often at the highest priority, the desire is to have it highly optimised. One way to do this is put everything into a very long method to avoid the overhead of message sends. Another might be to keep it logical split into several method for readability, but have those methods in-lined. I'm sure how pragmatic doing that would be, but it sparked my curiosity.... how do you go about designating a method/message to be inlined. I see OCASTTranslator>>visitMessageNode: (presumably) calls RBMessageNode>>isInlined which does a bundle of checks, for example RBMessageNode>>isInlineIf checks (#(ifTrue: ifFalse: ifTrue:ifFalse: ifFalse:ifTrue:) includes: self selector) ifFalse: But there also seems to be an <inline> pragma per WarpBlt>>rgbMap:from:to: What are the trade-off between these approaches, particularly for the special case where a method may have only one sender, where code is broken into small "private" methods mainly for readability. Also, do you need to manually supply the inlined bytecode yourself? cheers -ben

Jan. 2, 2016

[OT] Open source everything

by Eliot Miranda

Happy new year! http://gu.com/p/3q95q _,,,^..^,,,_ (phone)

Jan. 2, 2016

Re: [Pharo-dev] Happy new year 2016

by Sven Van Caekenberghe

I also thank everybody in the Pharo community for everything that was done in 2015. So much has happened, it was again hard to follow everything in detail. Both at the standard Pharo image and at the VM level, a massive amount of contributions came from everywhere. Many important projects around Pharo made great progress and delivered clear results. Thank you. 2016 will be at least as exciting, everything is set for us to continue moving forward. Sven > On 01 Jan 2016, at 16:57, 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 >

Jan. 1, 2016

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