September 2013 - Pharo-dev - lists.pharo.org

UI Mess

by Sean P. DeNigris

We have FileDialogWindow, which is a cool little class which implements all the cool things you may want to do when selecting a file, for example: - answer either a directory, file, file entry, etc. - set an initial directory - set the sorting block Life is good. <rant> Then, we take the entire domain of opening files and cram it into UITheme's chooseXyzFileAbcIn:j:k:l: methods. UITheme is also a nice little class... with 570 instance methods... wait, wth! Okay, but forgetting polymorph's design for a moment... Then, we take the handful of options that UITheme gives us and funnel those through UIManager, which exposes... 3. So out of the entire domain of selecting files, we have three safe options available. This doesn't seem to work. </rant> Naively, it seems to me that much of the original power could be retained if things were reversed a bit. For example, instead of implementing file selection functionality in three places (FileDialogWindow, UITheme, and UIManager), could we do: 1. FileDialogWindow implements the API for selecting files 2. UITheme only returns an appropriately-themed object (wth are "services" doing in UITheme anyway?!) 3. UIManager subclasses return either (via e.g. "UIManager default fileDialogWindow"): a) The themed object or b) a Dummy object that no-ops #1's API I'd be willing to give it a try if any of that sounds promising or if someone has a better idea. ----- Cheers, Sean -- View this message in context: http://forum.world.st/UI-Mess-tp4710579.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 26, 2013

Re: [Pharo-dev] [Vm-dev] Re: [NB] Trying to implement a ReadStream on NBExternalAddress

by Igor Stasenko

if we started about ideas.. what about good-old indirection? :) we could use extra object format with indirection to its data, with following layout: <header bitOr: PINNED><data pointer> so, the data (only for variable bytes, not var-references, of course) associated with such object can be located in separate non-movable region and you need to do extra work when scavenging objects with such special format, but for the rest, it almost the same: - the object (oop) itself can still move in memory, no big deal since its data pointer remains the same extending the idea, we could have even objects which pointing inside of an object.. like with Nicolas'es unboxed complex numbers, i could say: i want an object which points to imaginary field of unboxed complex value. so the complex value can be represented as a pinned object big enough to hold 2 floats: <header bitOr: PINNED><data pointer to 2 64-bit floats> and the object representing an imaginary float part can be following: <header bitOr: PINNED-SLAVE><complex oop><data pointer + 8> the main difference between PINNED and PINNED-SLAVE, that during scavenging, GC will ignore and won't deallocate the buffer pointed to by the slave, that's why it holds a reference to its master (<complex oop> in the example) to prevent deallocation/garbage collection of master and allocated buffer. in fact, PINNED-SLAVE format can be used for pointing in memory to anything (even outside memory managed by GC, because it never (de)allocates that memory), like that i can easily represent some data blob/buffer provided by external library as ByteArray object in image: <header bitOr: PINNED-SLAVE><nil><buffer pointer> -- Best regards, Igor Stasenko.

Sept. 26, 2013

[update 3.0] #30424

by Marcus Denker

30424 ----- 11684 Make Compiler unloadable part 1 https://pharo.fogbugz.com/f/cases/11684 11685 Make Compiler unloadable part 2 https://pharo.fogbugz.com/f/cases/11685 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Traits-MarcusDenker.572.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Slot-MarcusDenker.390.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/OpalCompiler-Core-MarcusDenke… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Kernel-MarcusDenker.1622.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Compiler-MarcusDenker.532.diff

Sept. 26, 2013

Re: [Pharo-dev] [Vm-dev] Re: [NB] Trying to implement a ReadStream on NBExternalAddress

by Igor Stasenko

On 24 September 2013 21:58, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > > On Mon, Sep 23, 2013 at 3:10 PM, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> Isn't Eliot just implementing this feature, having a segment of non >> relocatable objects? >> > > Sort of. Spur will allow any object in old space to stay still, and > through become can move any object to old space very simply. So instead of > having a special fixed space segment it has a best-bit compaction algorithm > that doesn't slide objects, but moves them into holes. With this kind of > compaction it is very easy to leave objects put. > > A further advantage of Spur is that objects have 64-bit alignment so > passing arrays to e.g. code using sse instructions, won't cause potential > alignment faults. > > But for NB see below on the hack that the ThreadedFFI uses. > > > >> >> 2013/9/23 Igor Stasenko <siguctua(a)gmail.com> >> >>> >>> >>> >>> On 23 September 2013 21:40, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>>> >>>> >>>> >>>> On 23 September 2013 16:23, Camillo Bruni <camillobruni(a)gmail.com>wrote: >>>> >>>>> Hi Jan, >>>>> >>>>> I think I will add the ByteArray accessor to NBExternalAddress today >>>>> or tomorrow since I need it as well for another project. >>>>> >>>>> hmm, reading from memory into bytearray can be done with memory copy: >>>> >>>> inputs: address , offset , size to read >>>> >>>> newAddress := NBExternalAddress value: address value + offset. >>>> buffer := ByteArray new: size. >>>> NativeBoost memCopy: newAddress to: buffer size: size. >>>> >>>> same way, writing, just swap the source and destination: >>>> >>>> newAddress := NBExternalAddress value: address value + offset. >>>> buffer "is given from somewhere". >>>> NativeBoost memCopy: buffer to: newAddress size: size. >>>> >>>> but as Jan noted, you cannot tell to write starting at specified offset >>>> from/to bytearray, e.g.: >>>> >>>> copy from: address to: buffer + someOffset >>>> neither: >>>> copy from: buffer + someOffset to: someAddress >>>> >>>> this where we need to introduce special 'field address' type, so you >>>> can construct it like this: >>>> >>>> offsetAddress := buffer nbAddressAt: offset. >>>> >>>> so then you can use it to pass to any function, which expects address, >>>> like memory copy >>>> or any foreign function. >>>> >>>> Since objects are moving in memory, we cannot calculate address of >>>> field before hand: >>>> >>>> address := NBExternalAddress value: someObject address + offset. >>>> >>>> because if GC will happen, after computing such address and its actual >>>> use, >>>> you will read/write to wrong location. >>>> >>> >>> ** after computing and *before* actual use ** >>> >>> >>>> Thus we should keep oop + offset up to the point of passing it to >>>> external function, under >>>> controllable conditions, that guarantee there's no GC is possible. >>>> >>>> >>>> Things would be much simpler if we could have pinning, isnt? :) >>> >> > Yes, but for the moment there is a hack one can use, a neat hack invented > by Andreas Raab. The Squeak GC is a two-space GC, old space (collected by > fullGC) and new space (collected by incrementalGC). An incrementalGC will > move objects in new space but leave objects on old space alone. A > tenuringIncrementalGC will compact new space and then make new space part > of old space. Therefore one way of nearly pinning objects is to do a young > GC to tenure objects into old space via tenuringIncrementalGC and then lock > fullGC, prevent fullGC from running, until the external call is finished. > All arguments to the call become old, and they won't be moved until the > fuuGCLock is released. This doesn't help passing a buffer that will be used > after the call returns, but it does help a buffer being passed to code that > might callback. > > This recipe feels like taking roots from voodoo cult :) and quite unreliable and limiting: - to ensure more or less 'stable' system behavior, you need to do fullGC before every such call - where is guarantee that user-code which implements callback won't produce enough garbage to force full GC? I'd prefer having strong public contract with VM that allows me to pin object(s) in memory, instead of relying on private details of VM's internals or, what is worse, on user's sanity :) Besides, one thing i found lately: its a pity that our object format don't using butterfly layout.. i realized that looking at some code, which tries pass an array of pointers.. and doing a lot of manual conversions for that.. while if we could have a butterfly headers, we could just pass an object pointer (like Array instance) as C array of pointers. > See uses of PrimErrObjectMayMove, e.g. ThreadedFFIPlugin>>primitiveCallout > and > platforms/Cross/plugins/FilePlugin/sqFilePluginBasicPrims.c>>sqFileReadIntoAt > > HTH > eliot > > -- Best regards, Igor Stasenko.

Sept. 26, 2013

Re: [Pharo-dev] [Pharo-users] [ANN] Launching Pharo on Ubuntu

by Damien Cassou

On Thu, Sep 26, 2013 at 2:04 PM, kilon <thekilon(a)yahoo.co.uk> wrote: > Is this why image launching fails, or is it unrelated ? open a new thread about that please. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Sept. 26, 2013

Re: [Pharo-dev] [Issue Tracker] input of submitters/bug fixers needed

by Camillo Bruni

On 2013-09-26, at 10:23, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > Marcus Denker-4 wrote >> The problem is that if we have over 500 entries, people just give up. >> They say "what use is it to fix 1, there are just too many". > > Okay, so I think a "Resolved" status like "Stale" would be a good > compromise. Then we can close the issue, but it will be tagged as to the > reason, so in my example I can have a filter for closed issues tagged Stale, > and easily reopen them if necessary. The problem is that now I have to wade > through hundreds of closed issues I worked on to find the ones that were > closed due to inactivity - not fun. we have a couple of statuses that come close to that: Resolved Postponed Resolved Won't Fix If you want we can decide upon Postponed and then close them. Could you check that this is in sync with the status description? https://pharo.fogbugz.com/default.asp?W65

Sept. 26, 2013

Re: [Pharo-dev] Pharo Launcher link

by Damien Cassou

On Wed, Sep 25, 2013 at 3:11 PM, kilon <thekilon(a)yahoo.co.uk> wrote: > Its not far from that goal at all. Congratulation for you work, you can > count me in as a contributor :) please send your code to smalltalkhub as soon as you have something and tell me. Thank you kilon -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Sept. 26, 2013

Re: [Pharo-dev] [Issue Tracker] input of submitters/bug fixers needed

by Sean P. DeNigris

Marcus Denker-4 wrote > The problem is that if we have over 500 entries, people just give up. > They say "what use is it to fix 1, there are just too many". Okay, so I think a "Resolved" status like "Stale" would be a good compromise. Then we can close the issue, but it will be tagged as to the reason, so in my example I can have a filter for closed issues tagged Stale, and easily reopen them if necessary. The problem is that now I have to wade through hundreds of closed issues I worked on to find the ones that were closed due to inactivity - not fun. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Issue-Tracker-input-of-submitters-bug-fixers-needed-t… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 26, 2013

Re: [Pharo-dev] A simple File browser ?

by Goubier Thierry

Le 26/09/2013 14:47, Marcus Denker a Ã©crit : > > On Sep 26, 2013, at 1:16 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > >> >> >> Le 26/09/2013 11:47, Erwan Douaille a Ã©crit : >>> >>> >>> >>> 2013/9/26 Goubier Thierry <thierry.goubier(a)cea.fr >>> <mailto:thierry.goubier@cea.fr>> >>> >>> Solution: >>> >>> (UIManager default chooseFullFileName: 'Choose an Icon' extensions: >>> nil path: nil preview: nil) asFileReference >>> >>> So coool :) Thanks ! >>> >>> We could probably clean up a bit those chooseXXX methods :) >>> >>> >>> Yes, just browsing it looks horrible :) >>> Just as a reminder, we should open an issue. >> >> And Marcus is saying we have too many open :) >> > > No, I am saying that if we just open but never close we will have a problem. > > Marcus > Yes, I know. I'm trying to close all the ones I have around at the moment before opening a new one :) Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Sept. 26, 2013

Re: [Pharo-dev] [PROVENANCE INTERNET] Re: A simple File browser ?

by Marcus Denker

On Sep 26, 2013, at 1:16 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > Le 26/09/2013 11:47, Erwan Douaille a Ã©crit : >> >> >> >> 2013/9/26 Goubier Thierry <thierry.goubier(a)cea.fr >> <mailto:thierry.goubier@cea.fr>> >> >> Solution: >> >> (UIManager default chooseFullFileName: 'Choose an Icon' extensions: >> nil path: nil preview: nil) asFileReference >> >> So coool :) Thanks ! >> >> We could probably clean up a bit those chooseXXX methods :) >> >> >> Yes, just browsing it looks horrible :) >> Just as a reminder, we should open an issue. > > And Marcus is saying we have too many open :) > No, I am saying that if we just open but never close we will have a problem. Marcus

Sept. 26, 2013