Pharo-dev
By thread
pharo-dev@lists.pharo.org
By month
Messages by month
- ----- 2026 -----
- July
- June
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
February 2016
- 65 participants
- 1055 messages
Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name
by Guille Polito
AAAANNNDDD! It looks I found the real cause of this!
- I tested an image pre-new session manager, and an image post-new
session manager. The issue only appeared in the latter.
- Checking, it seems that UUIDGenerator is not subscribed to the new
startup list. This means that the UUIDGenerator is not being
reinitialized on every startup. This means, moreover, that every person
that is loading the latest Pharo image is using the same UUIDGenerator
instance, with the same random seed => same generated UUIDs.
So, adding UUIDGenerator to the list would be the simplest solution and
the integration of NeoUUIDGenerator can be moved to Pharo6 maybe.
However, now that we found that something was missing in the startup
list, we should check for others...
Guille
On 02/09/2016 10:36 AM, Guille Polito wrote:
> Yes, go on. I think it is the easiest.
>
> Right now, to check if a slice is good or not I have to commit, browse
> Smalltalkhub's UI, and if it not good I have to delete the mcz
> manually...
>
> On 02/09/2016 10:10 AM, Sven Van Caekenberghe wrote:
>> You want me to do it then ?
>>
>> I don't want us to do double work ...
>>
>>> On 09 Feb 2016, at 10:09, Guillermo Polito
>>> <guillermopolito(a)gmail.com> wrote:
>>>
>>> Sad and true... :'(
>>>
>>> On Tue, Feb 9, 2016 at 10:01 AM, Sven Van Caekenberghe
>>> <sven(a)stfx.eu> wrote:
>>> Beside, you can't make slices ;-)
>>>
>>>> On 09 Feb 2016, at 09:58, Sven Van Caekenberghe <sven(a)stfx.eu> wrote:
>>>>
>>>> I can do the integration too, but I need some people to say go ahead.
>>>> I vote for replacing everything, there is no need for a plugin.
>>>>
>>>>> On 09 Feb 2016, at 09:25, Guille Polito
>>>>> <guillermopolito(a)gmail.com> wrote:
>>>>>
>>>>> Sven, just to answer your last question. The UUID generation right
>>>>> now generates the UUID fields like this:
>>>>>
>>>>> UUIDGenerator>>generateFieldsVersion4
>>>>>
>>>>> timeLow := self generateRandomBitsOfLength: 32.
>>>>> timeMid := self generateRandomBitsOfLength: 16.
>>>>> timeHiAndVersion := 16r4000 bitOr: (self
>>>>> generateRandomBitsOfLength: 12).
>>>>> clockSeqHiAndReserved := 16r80 bitOr: (self
>>>>> generateRandomBitsOfLength: 6).
>>>>> clockSeqLow := self generateRandomBitsOfLength: 8.
>>>>> node := self generateRandomBitsOfLength: 48.
>>>>>
>>>>> So... It's basically completely random. There is no part of the
>>>>> UUID that is actually based on the node, the clock or the time. It
>>>>> is actually a random string of bits that are generated using a
>>>>> number from /dev/urandom as seed (in linux).
>>>>>
>>>>> Does the mac VM include the plugin? (I do not have a mac any more
>>>>> to test fast ^^)
>>>>>
>>>>> I'll work on the integration of NeoUUID now, I hope this is the
>>>>> kind of issues that got integrated in code-freeze :)
>>>>>
>>>>> Guille
>>>>>
>>>>> On 02/08/2016 08:39 PM, Sven Van Caekenberghe wrote:
>>>>>> Here is a new version, in preparation of possible integration in
>>>>>> the main image:
>>>>>>
>>>>>> ===
>>>>>> Name: Neo-UUID-SvenVanCaekenberghe.2
>>>>>> Author: SvenVanCaekenberghe
>>>>>> Time: 8 February 2016, 8:33:04.141334 pm
>>>>>> UUID: a909453e-35dd-4c25-8273-62a9b2bd982e
>>>>>> Ancestors: Neo-UUID-SvenVanCaekenberghe.1
>>>>>>
>>>>>> Streamline UUID generation
>>>>>>
>>>>>> Add a current, shared instance
>>>>>>
>>>>>> Added better class and method comments
>>>>>>
>>>>>> Add more tests
>>>>>>
>>>>>> As suggested by Henrik Johansen, change to a version 0 UUID to
>>>>>> indicate that we follow a custom approach
>>>>>> ===
>>>>>>
>>>>>> The class comments now reads as follows:
>>>>>>
>>>>>> ===
>>>>>> I am NeoUUIDGenerator, I generate UUIDs.
>>>>>>
>>>>>> An RFC4122 Universally Unique Identifier (UUID) is an opaque
>>>>>> 128-bit number that can be used for identification purposes.
>>>>>> Concretely, a UUID is a 16 element byte array.
>>>>>>
>>>>>> The intent of UUIDs is to enable distributed systems to uniquely
>>>>>> identify information without significant central coordination. In
>>>>>> this context the word unique should be taken to mean "practically
>>>>>> unique" rather than "guaranteed unique".
>>>>>> I generate UUIDs similar, in spirit, to those defined in RFC4122,
>>>>>> though I use version 0 to indicate that I follow none of the
>>>>>> defined versions. This does not matter much, if at all, in practice.
>>>>>>
>>>>>> I try to conform to the following aspects:
>>>>>> - each 'node' (machine, image, instance) should generate unique
>>>>>> UUIDs
>>>>>> - even when generating UUIDs at a very fast rate, they should
>>>>>> remain unique
>>>>>> - be fast and efficient
>>>>>>
>>>>>> To achieve this goal, I
>>>>>> - take several aspects into account to generate a unique node ID
>>>>>> - combine a clock, a counter and some random bits
>>>>>> - hold a state, protected for multi user access
>>>>>>
>>>>>> I can generate about 500K UUIDs per second.
>>>>>>
>>>>>> Implementation:
>>>>>>
>>>>>> Although a UUID should be seen as totally opaque, here is the
>>>>>> concrete way I generate one:
>>>>>> - the first 8 bytes are the millisecond clock value with the
>>>>>> smallest quantity first; this means that the later of these 8
>>>>>> bytes will be identical when generated with small(er) timespans;
>>>>>> within the same millisecond, the full first 8 bytes will be
>>>>>> identical
>>>>>> - the next 2 bytes represent a counter with safe overflow, held
>>>>>> as protected state inside me; after 2*16 this value will repeat;
>>>>>> the counter initalizes with a random value
>>>>>> - the next 2 bytes are simply random, based on the system PRNG,
>>>>>> Random
>>>>>> - the final 4 bytes represent the node ID; the node ID is unique
>>>>>> per instance of me, across OS environments where the image might
>>>>>> run; the node ID is the MD5 hash of a string that is the
>>>>>> concatenation of several elements (see #computeNodeIdentifier)
>>>>>> Some bits are set to some predefined value, to indicate the
>>>>>> variant and version (see #setVariantAndVersion:)
>>>>>>
>>>>>> Usage:
>>>>>>
>>>>>> NeoUUIDGenerator next.
>>>>>> NeoUUIDGenerator current next.
>>>>>> NeoUUIDGenerator new next.
>>>>>>
>>>>>> Sharing an instance is more efficient and correct.
>>>>>> Instances should be reset whenever the image comes up.
>>>>>>
>>>>>> See also:
>>>>>>
>>>>>> http://en.wikipedia.org/wiki/UUID
>>>>>> https://tools.ietf.org/html/rfc4122
>>>>>> ===
>>>>>>
>>>>>> If we integrate this, I think we should replace the old generator
>>>>>> and the use of the primitive/plugin. But that requires at least
>>>>>> some support apart from me.
>>>>>>
>>>>>> And although I think that we should integrate this generator and
>>>>>> get rid of the plugin, I think there is probably an underlying
>>>>>> problem here (why did the generator fail ?) that could be
>>>>>> important to find.
>>>>>>
>>>>>> Sven
>>>>>>
>>>>>>> On 08 Feb 2016, at 10:38, Henrik Johansen
>>>>>>> <henrik.s.johansen(a)veloxit.no> wrote:
>>>>>>>
>>>>>>>> On 08 Feb 2016, at 10:29 , Sven Van Caekenberghe <sven(a)stfx.eu>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> 2) Misrepresenting the way the UUID was generated (a
>>>>>>>>> combination of node identifier + timestamp + random value,
>>>>>>>>> similar to type 3, but with differently sized/ordered fields)
>>>>>>>>> by marking it as being of type 4, which is defined to be UUID
>>>>>>>>> consisting of random bytes.
>>>>>>>>> IOW, I think it should be marked as type 0 instead of 4, so
>>>>>>>>> for the 1 person in each country who might be found to assume
>>>>>>>>> something about the implementation based on the type field,
>>>>>>>>> won't later feel he's been duped when checking the generator.
>>>>>>>> OK, I certainly want to change the type. Thing is, I cannot
>>>>>>>> find a reference to type 0 anywhere that I am looking (I mostly
>>>>>>>> used
>>>>>>>> https://en.wikipedia.org/wiki/Universally_unique_identifier)
>>>>>>>> Where did you find a definition of type 0 ? Or would that be a
>>>>>>>> way to say 'no specific type' then ?
>>>>>>> My rationale was that it is currently unassigned, and the least
>>>>>>> likely number to be chosen as identifier by new versions of the
>>>>>>> standard.
>>>>>>> IOW, for those who care, it might raise a "hmm, this is strange,
>>>>>>> better check the source", upon which they will discover it is
>>>>>>> generated in a non-standard fashion (but can verify for
>>>>>>> themselves it is generated in a way still pretty much guaranteed
>>>>>>> to be unique), and the rest... well, they can (most probably)
>>>>>>> keep on living happily without ever seeing a collision.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Henry
>>>
>
Feb. 9, 2016
Re: [Pharo-dev] Bloc Documentation
by Ben Coman
On Tue, Feb 9, 2016 at 4:15 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote:
> Bloc does not have examples yet.
> What classes/methods do you need to be commented first to understand the
> system?
>
> On Feb 9, 2016 4:46 AM, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote:
>>
>> I realize it's a fast-moving work in progress, but what's the best way to
>> try
>> to understand the system?
>>
>> For example, I saw class comments, some of which seem to be out of date,
>> and
>> I no longer see many of the examples I remember from last year - maybe I
>> have to load them separately?
Maybe... How about starting with some old fashioned hand sketches,
scanned, with maybe some audio attached to the static image describing
the architecture would give people the quickest start. Just like you
were introducing someone new who was sitting next to you -- but for
those of us aroudn the world who can't make there ;).
Or maybe (??) do an adhoc whiteboard presentation to a few people
locally that you video. It doesn't need to be nicely edited.
These might be quicker than sitting down to write class comments - and
maybe others can assist by extracting class comments from this
material.
cheers -ben
Feb. 9, 2016
Re: [Pharo-dev] Bloc Documentation
by Aliaksei Syrel
>
> Please add a comment in the method stating it.
> People are not reading your mind.
I know :) I'm arguing that some classes/method could wait. We need to
concentrate on most important ones. And then come to the rest.
On Tue, Feb 9, 2016 at 1:52 PM, stepharo <stepharo(a)free.fr> wrote:
> Please add a comment in the method stating it.
> People are not reading your mind.
>
> Stef
>
> Le 9/2/16 13:25, Aliaksei Syrel a écrit :
>
> formerOwner: anElementOrNil
>> "Set my former or remove property of argument is nil"
>>
>> anElementOrNil
>> ifNil: [ self removeProperty: #formerOwner ]
>> ifNotNil: [ self setProperty: #formerOwner toValue:
>> anElementOrNil ]
>
>
> I hate this method :) It is identical to Morph>>#formerOwner: (ctrl+c,
> ctrl+v)
> Basically it should be removed after reimplementation of drag&drop
> mechanism. Current one was copied from morphic to support compatibility.
> We will need to find better solution. Drag&drop is not so easy to do
> right. Help from community is appreciated :)
>
> Cheers,
> Alex
>
> On Tue, Feb 9, 2016 at 1:12 PM, Stephan Eggermont < <stephan(a)stack.nl>
> stephan(a)stack.nl> wrote:
>
>> formerOwner: anElementOrNil
>> "Set my former or remove property of argument is nil"
>>
>> anElementOrNil
>> ifNil: [ self removeProperty: #formerOwner ]
>> ifNotNil: [ self setProperty: #formerOwner toValue:
>> anElementOrNil ]
>>
>> I'd prefer to see a #setProperty:toValueOrRemove: there,
>> as that pattern is used a lot.
>>
>> Stephan
>>
>>
>>
>
>
Feb. 9, 2016
Re: [Pharo-dev] Bloc Documentation
by stepharo
Please add a comment in the method stating it.
People are not reading your mind.
Stef
Le 9/2/16 13:25, Aliaksei Syrel a écrit :
>
> formerOwner: anElementOrNil
> "Set my former or remove property of argument is nil"
>
> anElementOrNil
> ifNil: [ self removeProperty: #formerOwner ]
> ifNotNil: [ self setProperty: #formerOwner toValue: anElementOrNil ]
>
>
> I hate this method :) It is identical to Morph>>#formerOwner: (ctrl+c,
> ctrl+v)
> Basically it should be removed after reimplementation of drag&drop
> mechanism. Current one was copied from morphic to support compatibility.
> We will need to find better solution. Drag&drop is not so easy to do
> right. Help from community is appreciated :)
>
> Cheers,
> Alex
>
> On Tue, Feb 9, 2016 at 1:12 PM, Stephan Eggermont <stephan(a)stack.nl
> <mailto:stephan@stack.nl>> wrote:
>
> formerOwner: anElementOrNil
> "Set my former or remove property of argument is nil"
>
> anElementOrNil
> ifNil: [ self removeProperty: #formerOwner ]
> ifNotNil: [ self setProperty: #formerOwner
> toValue: anElementOrNil ]
>
> I'd prefer to see a #setProperty:toValueOrRemove: there,
> as that pattern is used a lot.
>
> Stephan
>
>
>
Feb. 9, 2016
Re: [Pharo-dev] Bloc Documentation
by stepharo
Le 9/2/16 11:53, Aliaksei Syrel a écrit :
> On Tue, Feb 9, 2016 at 11:39 AM, Esteban Lorenzano
> <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote:
>
> mmm⦠thatâs a bad question because I would answer âall of themâ,
> but I understand you want to do a step to make easy for us to
> understand so my answer has to be âthe important onesâ, but since
> there is no documentation/class comments/examples I just cannot
> know which them, so is up to you (and people doing bloc) to tell
> us which are âthe important onesâ⦠by adding class comments and
> examples! :D
>
>
> It depends :) There are a lot of obvious places in Bloc that do not
> necessarily need documentation to understand them. For example
> events. BlLostMouseFocusEvent does not need any "serious"
> documentation in first place. If you want to find out when it is being
> sent it is much faster to do cmd+n then read long class doc. I don't
> want to say that we don't need documentation.. I just want to say that
> with amount of available man-power we can't instantly add
> documentation to everything in bloc.
Sorry but if the class has an example and a comment stating.
If you want to react to LostMouseFocus do it like that
self eventListener: #LostMouseFocus
Then this is just great. So a comment is not only about what the class
does but how to use it.
Stef
>
> So I'm asking: what parts of Bloc do you find especially complicated
> to understand. so we could concentrate on them? Root class
> BlElement(methods) has good doc, so please use it to start your
> exploration journey.
>
> Cheers,
> Alex
Feb. 9, 2016
Re: [Pharo-dev] Some questions
by Esteban Lorenzano
> On 09 Feb 2016, at 13:38, Stéphane Ducasse <stephane.ducasse(a)inria.fr> wrote:
>
>>
>> p.s. To all who see this email: Bloc needs more complains
>>
>> :)
>>
>> Some random thoughts:
>> BlWorldElement and BlSpaceElement sounds like this is for elements *in* space or *in* world, not like
>> *the* WorldElement.
>
> I agree
> I think that BlWorldEllement should be BlWorld and BlSpaceElement should be BlSpace
in general, using âelementâ seems to be just as using âobjectâ :P
>
>
>> Looking at BlElement definition:
>>
>> Object subclass: #BlElement
>> uses: TBlPropertiesOwner
>> instanceVariableNames: 'ownerReference visible properties layoutProperties zIndex spaceReference eventListener errorOnDraw locked extent shape layoutStrategy children nextElementReference previousElementReference measuredExtent requestingLayout oldExtentMeasurementSpec transformation'
>> classVariableNames: ''
>> package: 'Bloc-Core-!Core-Basic'
>>
>> The properties visible and locked, somehow they don't fit in the structure a BlElement provides, I don't know why but it looks strange.
>> zIndex: what defines the order of elements, its zIndex or *are* they in different Bloc-Layers and a zIndex would be superfluous?
>>
>> Are measuredExtent requestingLayout oldExtentMeasurementSpec attributes, a BlElement always has and needs, or are they only used during layouting?
>>
>> children ownerReference nextElementReference previousElementReference, would it make sense to encapsulate this in one new class, something like a treeNode/structureNode?
>>
>>
>>
>>
>> Cheers,
>> Alex
>>
>
> --------------------------------------------
> Stéphane Ducasse
> http://stephane.ducasse.free.fr <http://stephane.ducasse.free.fr/>
> http://www.synectique.eu <http://www.synectique.eu/> / http://www.pharo.org <http://www.pharo.org/>
> 03 59 35 87 52
> Assistant: Julie Jonas
> 03 59 57 78 50
> 03 59 35 86 16
>
> S. Ducasse - Inria
> 40, avenue Halley,
> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
> Villeneuve d'Ascq 59650
> France
Feb. 9, 2016
Re: [Pharo-dev] Spec Experience in Need for Feedback :)
by stepharo
Hi nicolai
I agree. I will have a look at the Calipso experience of Alain.
Because may be Calipso + Spec layout format would be much nicer.
Did you look at it?
Alain just brainstormed but this is interesting for thinking.
Stef
What I hate also is that the
AbstractApdate>>update: aSymbol
self changed: aSymbol
This is a bit terrible because the adpater should not exist at runtime
and adapter should just encapsulate how to create and set the communication
between the model and the view. Now it is in the middle and this is not
good.
stef
Le 8/2/16 11:31, Nicolai Hess a écrit :
>
>
> 2016-02-08 10:37 GMT+01:00 stepharo <stepharo(a)free.fr
> <mailto:stepharo@free.fr>>:
>
> Hi guys
>
> I should say that I'm sick (gift from my little boy) so may be
> this is obvious.
>
> I'm looking at the code of Spec and I hate this code :)
>
> widgetDo: aBlock
>
> ^ self widget ifNotNil: aBlock
>
>
> I do not see why widgetDo: has to test for nil
> So I transformed
>
> widgetDo: aBlock
>
> ^ self widget ifNotNil: aBlock
>
> into
>
>
> widgetDo: aBlock
>
> ^ aBlock cull: self widget
>
> BTW I hate all the cull: call. They are connected with
> sloppiness). It is far too easy to use cull:
> I do not know how many arguments, I do not care I use cull:
> cull: is slow slow and help producing messing API.
>
> And it broke. The methodBrowser example did not work anymore and
> many others.
> Debugger felt down....
> I feel sad. Now my brain is dead so I cannot concentrate more.
>
>
> Stef
>
>
> This is a big problem with morphic/spec ui elements. You never know
> for sure
> what code this
> self update ---> search through all (dynamicly added) dependents and
> notify
> will finally call.
> In this example we are about to *built* the widgets and in this run ,
> we change a component that
> will update all dependents goes back and forth between model, adapter
> and widget. And all
> before the widget is actually accessible for the widgetDo: call.
>
> (and, REALLY we need to clean this up. This is really bad code if we
> announce a textChanged announcement for
> a text component, if we *initialize* an *empty textcomponent* with an
> *empty text*!).
>
>
Feb. 9, 2016
[pharo-project/pharo-core] 328356: 50572
by GitHub
Branch: refs/heads/5.0
Home: https://github.com/pharo-project/pharo-core
Commit: 328356dc854a25a48d3fd46972fe68bc410df50e
https://github.com/pharo-project/pharo-core/commit/328356dc854a25a48d3fd469…
Author: Jenkins Build Server <board(a)pharo-project.org>
Date: 2016-02-09 (Tue, 09 Feb 2016)
Changed paths:
A ConfigurationOfUnifiedFFI.package/ConfigurationOfUnifiedFFI.class/instance/baselines/baseline0%5F12_.st
M ConfigurationOfUnifiedFFI.package/ConfigurationOfUnifiedFFI.class/instance/symbolic versions/development_.st
M ConfigurationOfUnifiedFFI.package/ConfigurationOfUnifiedFFI.class/instance/symbolic versions/stable_.st
A ConfigurationOfUnifiedFFI.package/ConfigurationOfUnifiedFFI.class/instance/versions/v0%5F11%5F3_.st
A ConfigurationOfUnifiedFFI.package/ConfigurationOfUnifiedFFI.class/instance/versions/v0%5F12%5F1_.st
A ConfigurationOfUnifiedFFI.package/ConfigurationOfUnifiedFFI.class/instance/versions/v0%5F12_.st
R FFI-Tests.package/FFIPluginTests.class/README.md
R FFI-Tests.package/FFIPluginTests.class/definition.st
R FFI-Tests.package/FFIPluginTests.class/instance/external form tests/testBlitToAndFromExternalForm.st
R FFI-Tests.package/FFIPluginTests.class/instance/other tests/testLoadSymbolFromModule.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple tests/testConstructedCharCall.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple tests/testConstructedDoubleCall.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple tests/testConstructedFloatCall.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple tests/testConstructedIntCall.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple tests/testConstructedPrintString.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple tests/testConstructedShortCall.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple tests/testGenericCharCall.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple tests/testGenericDoubleCall.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple tests/testGenericDoubleCall2.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple tests/testGenericFloatCall.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple tests/testGenericIntCall.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple tests/testGenericMixedDoublesIntAndStruct.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple tests/testGenericMixedFloatsAndDouble.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple tests/testGenericPrintString.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple tests/testGenericShortCall.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple tests/testLibraryCharCall.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple tests/testLibraryDoubleCall.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple tests/testLibraryFloatCall.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple tests/testLibraryIntCall.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple tests/testLibraryPrintString.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple tests/testLongLongA1.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple tests/testLongLongA3.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple tests/testLongLongs.st
R FFI-Tests.package/FFIPluginTests.class/instance/simple tests/testUlongRange.st
R FFI-Tests.package/FFIPluginTests.class/instance/structure tests/testMixedIntAndStruct.st
R FFI-Tests.package/FFIPluginTests.class/instance/structure tests/testMixedIntAndStruct2.st
R FFI-Tests.package/FFIPluginTests.class/instance/structure tests/testMixedIntAndStruct3.st
R FFI-Tests.package/FFIPluginTests.class/instance/structure tests/testPoint2.st
R FFI-Tests.package/FFIPluginTests.class/instance/structure tests/testPoint4.st
R FFI-Tests.package/FFIPluginTests.class/instance/structure tests/testPointers.st
R FFI-Tests.package/FFIPluginTests.class/instance/structure tests/testSmallStructureReturn.st
R FFI-Tests.package/FFISmallStruct1.class/README.md
R FFI-Tests.package/FFISmallStruct1.class/class/as yet unclassified/fields.st
R FFI-Tests.package/FFISmallStruct1.class/definition.st
R FFI-Tests.package/FFISmallStruct1.class/instance/accessing/x.st
R FFI-Tests.package/FFISmallStruct1.class/instance/accessing/x_.st
R FFI-Tests.package/FFISmallStruct1.class/instance/accessing/y.st
R FFI-Tests.package/FFISmallStruct1.class/instance/accessing/y_.st
R FFI-Tests.package/FFITestLibrary.class/README.md
R FFI-Tests.package/FFITestLibrary.class/class/accessing/moduleName.st
R FFI-Tests.package/FFITestLibrary.class/class/primitives/ffiPrintString_.st
R FFI-Tests.package/FFITestLibrary.class/class/primitives/ffiTestChar_with_with_with_.st
R FFI-Tests.package/FFITestLibrary.class/class/primitives/ffiTestDoubles9_d_d_d_d_d_d_d_d_.st
R FFI-Tests.package/FFITestLibrary.class/class/primitives/ffiTestDoubles_with_.st
R FFI-Tests.package/FFITestLibrary.class/class/primitives/ffiTestFloats_with_.st
R FFI-Tests.package/FFITestLibrary.class/class/primitives/ffiTestInt_with_with_with_.st
R FFI-Tests.package/FFITestLibrary.class/class/primitives/ffiTestLongLongA1_with_with_.st
R FFI-Tests.package/FFITestLibrary.class/class/primitives/ffiTestLongLongA3_with_with_.st
R FFI-Tests.package/FFITestLibrary.class/class/primitives/ffiTestLongLong_with_.st
R FFI-Tests.package/FFITestLibrary.class/class/primitives/ffiTestMixedDoublesIntAndStruct_d_d_d_d_d_d_d_d_i_s_.st
R FFI-Tests.package/FFITestLibrary.class/class/primitives/ffiTestMixedFloatsAndDouble_with_with_with_.st
R FFI-Tests.package/FFITestLibrary.class/class/primitives/ffiTestMixedIntAndStruct2_with_.st
R FFI-Tests.package/FFITestLibrary.class/class/primitives/ffiTestMixedIntAndStruct3_with_.st
R FFI-Tests.package/FFITestLibrary.class/class/primitives/ffiTestMixedIntAndStruct_with_with_.st
R FFI-Tests.package/FFITestLibrary.class/class/primitives/ffiTestPoint2_with_.st
R FFI-Tests.package/FFITestLibrary.class/class/primitives/ffiTestPoint4_with_.st
R FFI-Tests.package/FFITestLibrary.class/class/primitives/ffiTestPointers_with_.st
R FFI-Tests.package/FFITestLibrary.class/class/primitives/ffiTestShort_with_with_with_.st
R FFI-Tests.package/FFITestLibrary.class/class/primitives/ffiTestSmallStructReturn.st
R FFI-Tests.package/FFITestLibrary.class/class/primitives/ffiTestUlong_with_with_with_.st
R FFI-Tests.package/FFITestLibrary.class/definition.st
R FFI-Tests.package/FFITestLibrary.class/instance/primitives/ffiPrintString_.st
R FFI-Tests.package/FFITestLibrary.class/instance/primitives/ffiTestChar_with_with_with_.st
R FFI-Tests.package/FFITestLibrary.class/instance/primitives/ffiTestDoubles_with_.st
R FFI-Tests.package/FFITestLibrary.class/instance/primitives/ffiTestFloats_with_.st
R FFI-Tests.package/FFITestLibrary.class/instance/primitives/ffiTestInt_with_with_with_.st
R FFI-Tests.package/FFITestLibrary.class/instance/primitives/ffiTestShort_with_with_with_.st
R FFI-Tests.package/FFITestPoint2.class/README.md
R FFI-Tests.package/FFITestPoint2.class/class/field definition/fields.st
R FFI-Tests.package/FFITestPoint2.class/definition.st
R FFI-Tests.package/FFITestPoint2.class/instance/accessing/x.st
R FFI-Tests.package/FFITestPoint2.class/instance/accessing/x_.st
R FFI-Tests.package/FFITestPoint2.class/instance/accessing/y.st
R FFI-Tests.package/FFITestPoint2.class/instance/accessing/y_.st
R FFI-Tests.package/FFITestPoint4.class/README.md
R FFI-Tests.package/FFITestPoint4.class/class/field definition/fields.st
R FFI-Tests.package/FFITestPoint4.class/definition.st
R FFI-Tests.package/FFITestPoint4.class/instance/accessing/w.st
R FFI-Tests.package/FFITestPoint4.class/instance/accessing/w_.st
R FFI-Tests.package/FFITestPoint4.class/instance/accessing/x.st
R FFI-Tests.package/FFITestPoint4.class/instance/accessing/x_.st
R FFI-Tests.package/FFITestPoint4.class/instance/accessing/y.st
R FFI-Tests.package/FFITestPoint4.class/instance/accessing/y_.st
R FFI-Tests.package/FFITestPoint4.class/instance/accessing/z.st
R FFI-Tests.package/FFITestPoint4.class/instance/accessing/z_.st
M ScriptLoader50.package/ScriptLoader.class/instance/load primitives/loadConfiguration_version_.st
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50571.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50572.st
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50571.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50572.st
M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
M UnifiedFFI-Tests.package/FFICalloutAPITests.class/instance/accessing/ffiLibraryName.st
A UnifiedFFI-Tests.package/FFICalloutAPITests.class/instance/primitives atomic/ffiCopyString_to_.st
A UnifiedFFI-Tests.package/FFICalloutAPITests.class/instance/primitives atomic/ffiDoubleAbs_.st
A UnifiedFFI-Tests.package/FFICalloutAPITests.class/instance/primitives atomic/ffiFloatAbs_.st
A UnifiedFFI-Tests.package/FFICalloutAPITests.class/instance/primitives atomic/ffiIntAbs_.st
A UnifiedFFI-Tests.package/FFICalloutAPITests.class/instance/primitives atomic/ffiLongLongAbs_.st
R UnifiedFFI-Tests.package/FFICalloutAPITests.class/instance/primitives atomic/ffiPrintString_.st
R UnifiedFFI-Tests.package/FFICalloutAPITests.class/instance/primitives atomic/ffiTestChar_with_with_with_.st
R UnifiedFFI-Tests.package/FFICalloutAPITests.class/instance/primitives atomic/ffiTestDoubles_with_.st
R UnifiedFFI-Tests.package/FFICalloutAPITests.class/instance/primitives atomic/ffiTestFloats_with_.st
R UnifiedFFI-Tests.package/FFICalloutAPITests.class/instance/primitives atomic/ffiTestInt_with_with_with_.st
R UnifiedFFI-Tests.package/FFICalloutAPITests.class/instance/primitives atomic/ffiTestLongLong_with_.st
R UnifiedFFI-Tests.package/FFICalloutAPITests.class/instance/primitives atomic/ffiTestShort_with_with_with_.st
R UnifiedFFI-Tests.package/FFICalloutAPITests.class/instance/primitives atomic/ffiTestUlong_with_with_with_.st
A UnifiedFFI-Tests.package/FFICalloutAPITests.class/instance/primitives atomic/ffiToLower_.st
A UnifiedFFI-Tests.package/FFICalloutAPITests.class/instance/primitives constant/ffiTestContantFormat_to_.st
A UnifiedFFI-Tests.package/FFICalloutAPITests.class/instance/primitives constant/ffiTestContantFormat_value_to_.st
R UnifiedFFI-Tests.package/FFICalloutAPITests.class/instance/primitives constant/ffiTestIntConstant.st
R UnifiedFFI-Tests.package/FFICalloutAPITests.class/instance/primitives constant/ffiTestIntConstantWith_.st
A UnifiedFFI-Tests.package/FFICalloutAPITests.class/instance/primitives pointer/primFromByteArray_toExternalAddress_size_.st
M UnifiedFFI-Tests.package/FFICalloutAPITests.class/instance/tests atomic/testCharCall.st
M UnifiedFFI-Tests.package/FFICalloutAPITests.class/instance/tests atomic/testDoubleCall.st
M UnifiedFFI-Tests.package/FFICalloutAPITests.class/instance/tests atomic/testFloatCall.st
M UnifiedFFI-Tests.package/FFICalloutAPITests.class/instance/tests atomic/testIntCall.st
M UnifiedFFI-Tests.package/FFICalloutAPITests.class/instance/tests atomic/testLongLongs.st
M UnifiedFFI-Tests.package/FFICalloutAPITests.class/instance/tests atomic/testPrintString.st
R UnifiedFFI-Tests.package/FFICalloutAPITests.class/instance/tests atomic/testShortCall.st
R UnifiedFFI-Tests.package/FFICalloutAPITests.class/instance/tests atomic/testUlongRange.st
A UnifiedFFI-Tests.package/FFICalloutAPITests.class/instance/tests constant/testCallWithAllConstParameter.st
A UnifiedFFI-Tests.package/FFICalloutAPITests.class/instance/tests constant/testCallWithConstParameter.st
R UnifiedFFI-Tests.package/FFICalloutAPITests.class/instance/tests constant/testIntCallWithAllConstParameter.st
R UnifiedFFI-Tests.package/FFICalloutAPITests.class/instance/tests constant/testIntCallWithConstParameter.st
A UnifiedFFI-Tests.package/FFICalloutAPITests.class/instance/tests pointer/testByteArrayToExternalAddress.st
M UnifiedFFI-Tests.package/FFICalloutTests.class/instance/tests/testBuildingFnSpec.st
M UnifiedFFI.package/FFICallout.class/class/class initialization/initializeTypeAliases.st
R UnifiedFFI.package/FFIExternalObject.class/class/as yet unclassified/finalizeResourceData_.st
A UnifiedFFI.package/FFIExternalObject.class/class/finalization/finalizeResourceData_.st
M UnifiedFFI.package/FFIExternalStructure.class/class/private/compileFields_withAccessors_.st
M UnifiedFFI.package/FFIMethodRegistry.class/class/class initialization/initializeStartUpList.st
A UnifiedFFI.package/FFIOop.class/instance/private/basicHandle_at_.st
A UnifiedFFI.package/FFIOop.class/instance/private/basicHandle_at_put_.st
M UnifiedFFI.package/extension/ExternalAddress/instance/adoptAddress_.st
M UnifiedFFI.package/extension/Integer/instance/asExternalTypeOn_.st
A UnifiedFFI.package/extension/SmallInteger/instance/unrollFromArity_.st
Log Message:
-----------
50572
Pharo
http://files.pharo.org/image/50/50572.zip
Feb. 9, 2016
[pharo-project/pharo-core]
by GitHub
Branch: refs/tags/50572
Home: https://github.com/pharo-project/pharo-core
Feb. 9, 2016
Re: [Pharo-dev] Bloc Documentation
by Aliaksei Syrel
>
> A lot of confusing comes from BlMorphXX things still being around all over
> the place. I prefer good examples as a starting point. Making
> Bloc-DragPanels work again?
Exactly! :) We just physically can't do everything so fast. It will come!
Patience, patience :)
Nevertheless pointing to issues is very helpful, keep doing it
Cheers,
Alex
On Tue, Feb 9, 2016 at 1:24 PM, Stephan Eggermont <stephan(a)stack.nl> wrote:
> On 09/02/16 11:53, Aliaksei Syrel wrote:
>
>> So I'm asking: what parts of Bloc do you find especially complicated to
>> understand. so we could concentrate on them? Root class
>> BlElement(methods) has good doc, so please use it to start your
>> exploration journey.
>>
>
> A lot of confusing comes from BlMorphXX things still being around all over
> the place. I prefer good examples as a starting point. Making
> Bloc-DragPanels work again?
>
> Stephan
>
>
>
>
Feb. 9, 2016