[Pharo-dev] Re: Progress Report -> Refactoring Project - ( May 3 - May 7)

[Sean P. DeNigris]

EVELYN CUSI LOPEZ wrote
> Tasks for this week:
> - Fix issue: RB - Improve instance variable refactoring #8665

Glad to see this on the horizon! This is an important one. It can be a big
gotcha for us naive users. I added a comment to the issue - hope it helps.



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

[Pharo-dev] Re: Improving Variable Shadow model

[Sean P. DeNigris]

Thanks for the detailed writeup, Marcus. Very interesting and looks like good
work :)



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

[Pharo-dev] Re: Proposal: Simplify How Pragmas are stored

[Sean P. DeNigris]

Marcus Denker-4 wrote
> This will speedup both pragma access and property access and will
> radically simplify the code.

A little over my head, but sounds great!



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

[Pharo-dev] Re: Progress Report -> Refactoring Project - ( March 29 - April 1 )

[Sean P. DeNigris]

EVELYN CUSI LOPEZ wrote
> Last week I did these tasks:

Looks like great progress. Thanks :)



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

[Pharo-dev] Re: Progress Report -> Refactoring Project - ( February 8 - 12 )

[Sean P. DeNigris]

EVELYN CUSI LOPEZ wrote
> the loss of variable values would be when you
> have live instances at the time of refactoring, right?

Exactly



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

[Pharo-dev] Re: Progress Report -> Refactoring Project - ( February 8 - 12 )

[Sean P. DeNigris]

More great progress, Evelyn! Did you see my question on your last update
thread RE data loss when pushing up instance variables?



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

[Pharo-dev] Re: Progress Report -> Refactoring Project - ( February 1 - 5 )

[Sean P. DeNigris]

Wonderful to have progress on this important topic - thank you!

Sorry I haven't been following closely (maybe you addressed it already), but
pushing up instance variables has a dangerous limitation - instances lose
any data held in that var. I guess it's because it's deleted from the
subclass prior to adding to the superclass to avoid duplicating. One
solution would be to add a var to the superclass with a mangled name, copy
the data for all instances, remove the var from the subclass, and then
rename the mangled var.



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

[Pharo-dev] Re: Abut writeOn: versus storeOn:

[Sean P. DeNigris]

Stéphane Ducasse wrote
> I saw that a couple of collections implement writeOn: in addition to
> storeOn: and I was wondering if someone knows
> the reason. My gut feeling is that this is somehow dead code.

#Part 1: Do we need writeOn:?


I did some digging, but there was nothing conclusive to my eyes, although I
"smelled" the same thing you did. I am documenting here in case it helps...

One of the implementors is ShortIntegerArray. Its comment says it "is an
array for efficiently representing integers in the 16bit range." Although
it's in the Balloon package, its only user (other than objects that
initialize it) seems to be FT2Outline.

The other is ArrayedCollection, which has this comment for #writeOn: "Store
the array of bits onto the argument, aStream.  (leading byte ~= 16r80)
identifies this as raw bits (uncompressed).  Always store in Big Endian
(Mac) byte order.  Do the writing at BitBlt speeds. We only intend this for
non-pointer arrays.  Do nothing if I contain pointers."

The header and mention of BitBlt make that comment seem similar to another
implementor, Bitmap>>#writeOn: - "Store the array of bits onto the argument,
aStream. A leading byte of 16r80 identifies this as compressed by
compressToByteArray (qv)."

Form and MatrixTransform2x3 are other implementors that seem related, as
graphics artifacts.

Then there is RunArray - a seeming outlier - and several Zinc classes.

The clearest case seems to be Zinc, which seems to have this as a domain
concept, and has senders and implementors.

Other than Zinc, there are very few senders of the message.

There is FLEncoder, which seems like it could be legitimate, but it sends
the message from #encodeBitmap:, which is itself not sent. Same for
Form>>#writeBitsOn: (no senders)

The final sender is MCDataStream.

#Part 2: What is the distinction between writeOn: and storeOn:?



Stéphane Ducasse wrote
> Because readOn: logic is the inverse of storeOn: and I was wondering what
> is the equivalent for writeOn:

I'm not sure that this part is correct. I think storeOn: is orthogonal, and
#readOn: seems like the inverse from a native English perspective (e.g.
Magritte uses the terms read/write), but there are no implementors of
#readOn: in P8.

There was a recent discussion about #storeOn: and whether it is still useful
on Discord general channel. The most illuminating comment was:
Martin McClure 12/01/2020
@svenvc @Esteban A. Maringolo #storeString and #storeOn: are Smalltalk-80.
Page 101 of the Blue Book says of storeString, "Answer a String
representation of the receiver from which the receiver can be
reconstructed." The representation is always Smalltalk source code, the
"reconstruction" is evaluation by the compiler.

Here are all the posts in chronological order:

svenvc 12/01/2020
For the sake of discussion, what is a useful store string (for some standard
class in the image) ?
 
Esteban A. Maringolo 12/01/2020
For me a "store string" is an expression that instantiates the receiver
back.
👍
 
SeanDeNigris 12/01/2020
For Morphs, off the top of my head, it’s actually really cool because you
can re-create more from a prototype
 
Esteban A. Maringolo 12/01/2020
But it's a weak serialization mechanism, or at least it is fragile.
[8:44 AM]
(recursions, etc.)
 
SeanDeNigris 12/01/2020
I also use it to generate code in Magritte. The store string for the
description is the expression that is returned from the descriptions getter
Serializing blocks is a tough problem in general. I went through a lot of
grief because fuel will let you serialized them but depends on the outer
context not having changed to rematerialize, even for clean blocks, with no
hook to fix things if it has changed, making data unloadable
 
Esteban A. Maringolo 12/01/2020
It should only serialize clean blocks or give you a way to resolve the
closures.

@Esteban A. Maringolo
For me a "store string" is an expression that instantiates the receiver
back.
 
svenvc 12/01/2020
yes, that is it, but by definition it means that it depends on the compiler.
there is also no real specification of what the output looks like (like
JSON, XML, STON, or any other textual/binary format). it feels quite weird.
 
Esteban A. Maringolo 12/01/2020
I don't ask for specification, but historically storeOn: aStream always was
"smalltalk" expressions.
[9:11 AM]
at least in my experience, and even "actual" use (not that I chose to use
it, but a customer does).
 
gcorriga 12/01/2020
#storeSting is useful when debugging, or when doing exploratory coding.
[10:24 AM]
e.g. I have a complex data structure, I can send #storeString to it to get a
text representation I can use e.g in a unit test.

Martin McClure 12/01/2020
@svenvc @Esteban A. Maringolo #storeString and #storeOn: are Smalltalk-80.
Page 101 of the Blue Book says of storeString, "Answer a String
representation of the receiver from which the receiver can be
reconstructed." The representation is always Smalltalk source code, the
"reconstruction" is evaluation by th

[Pharo-dev] Re: Progress Report -> Refactoring Project - (November 30 - December 4)

[Sean P. DeNigris]

Sounds great! Thanks for the update :) Keep us posted...



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

[Pharo-dev] Re: This week (49/2020) on the Issue Tracker

[Sean P. DeNigris]

Wow! Impressive list :)


Marcus Denker-4 wrote
> - Activation in single click (which triggers column expansion) is now
> default for inspections (it was double click, but it felt weird).

-1 on this. The problem with single click is that it adds a column even when
you don't want it to. This was very annoying. IMO after using the
double-click for a few months (it took that long to get used to it), the
extra click is significantly less disruptive than the unnecessary column
adding.



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

[Pharo-dev] Re: This week (47/2020) on the Issue Tracker

[Sean P. DeNigris]

Marcus Denker-4 wrote
> Question: are these mails interesting? Do they have enough information
> added to 
> have value?

Yes! Please continue. I like that they are brief because too much detail can
be overwhelming and we can always ask questions about items that seem
interesting. IHMO the only extra info worth adding (if there's ever the
time) is the "why" - motivation and summaries of internal discussions that
we wouldn't understand just by looking at the commits...



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

[Pharo-dev] Re: AST Transformation Techniques

[Sean P. DeNigris]

hogoww wrote
> I'm aware of Julien Delplanque which has done something a bit like this, 
> or my own project.

Thanks! Both interesting and good to know about. Your project took me a
while to understand by reading and rereading the examples in the readme, but
I really like the block idea. I think Julien's could work for my use case
because there is a feature to generate his AST model from an existing
method. One day, I'd love to sit down and properly compare all three
approaches. I'll add it to the never-ending TODOs!



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

[Pharo-dev] Re: [ANN] Libgit 1.0.0 in Pharo 9

[Sean P. DeNigris]

teso...@gmail.com wrote
> Esteban is working on having a nice OBS configuration
> for the VM extending what Holger has previously done

Awesome! I code on Mac, but this is super important to the community and
often for deployment...



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

[Pharo-dev] Re: This week (41/2020) on the Issue Tracker

[Sean P. DeNigris]

Marcus Denker-4 wrote
> This week (41/2020) on the Issue Tracker
> This one puts a focus on *merged* PRs to Pharo itself only and sorts them
> by category with a 
> little bit of context.

Thanks, Marcus! Indeed this one seems much nicer :)



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

[Pharo-dev] Re: [ANN] Pharo Consortium New Academic Member: Laboratoire DISP

[Sean P. DeNigris]

Great news!!



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] OSProcess and CommandShell updated on GitHub for Pharo

[Sean P. DeNigris]

Thanks, Dave!!



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Halos Broken - P9 Headless

[Sean P. DeNigris]

Sean P. DeNigris wrote
> Morphic halos don't seem to be working with the Pharo 9 headless VM. They
> seem fine with headful.

Still a bug as of Build information:
Pharo-9.0.0+build.572.sha.308d3ba56ee06f02c3d3f916da5636d04ceca15b (64 Bit)

https://github.com/pharo-project/opensmalltalk-vm/issues/100




-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

[Pharo-dev] Robust Functionality vs. Minimalism (was "Microdown ?")

[Sean P. DeNigris]

I wonder whether/how-best to apply our principle of minimalism when it
applies to areas of the system that, while critical, seem inherently
non-minimalist e.g. test harnesses, documentation, etc. 

I thought a lot about this when trying to document and refactor SDL. The
lack 
of a mock library in core was a big barrier to understanding the 
interactions between SDL objects. Maybe I'm being naive, but I feel like if 
someone wants a minimal image, they're not going to want to load SUnit or 
rich text documentation *at all*, so I don't see the risk-benefit of 
crippling these features. 

This also applies to Pillar/Microdown. While *any* rich text comments are an
exciting development, I'd like to understand the benefit of Microdown vs.
full Pillar syntax. 
Presumably the primary benefit is the size of the codebase. Any other
reasons?
A few other questions about the "rich text doc" roadmap: 
1. Could/will this be extended to method comments? That would be really cool 
:) 
2. How close are we for someone to use full Pillar syntax in class comments 
in their own library? Any plans to make this possible? 
NB. I originally posted a version of this on an older thread about Pillar
but and I'm assuming it may have gotten lost in that limited context.



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Microdown ?

[Sean P. DeNigris]

NorbertHartl wrote
> Microdown is a subset of markdown that can parse to a pillar model. So the
> discussions about pillar markup have finally settled and we have a syntax
> format that reads well in ascii which can be used in class comments even
> if it is a basic image.

Rich text comments are an exciting development!

I'd like to understand the benefit of Microdown vs. full Pillar syntax.
Presumably the primary benefit is the size of the codebase. Any other
reasons?

Generally, I wonder about minimalism when it applies to areas of the system
that seem inherently non-minimalist e.g. test harnesses, documentation, etc.
I though a lot about this when trying to document and refactor SDL. The lack
of a mock library in core was a big barrier to understanding the
interactions between SDL objects. Maybe I'm being naive, but I feel like if
someone wants a minimal image, they're not going to want to load SUnit or
rich text documentation *at all*, so I don't see the risk-benefit of
crippling these features.

A few other questions about the "rich text doc" roadmap:
1. Could/will this be extended to method comments? That would be really cool
:)
2. How close are we for someone to use full Pillar syntax in class comments
in their own library? Any plans to make this possible?



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Microdown ?

[Sean P. DeNigris]

Pharo Smalltalk Developers mailing list wrote
> With MicroPrint, you can do this:

Was that a typo, or is there another library called "MicroPrint"?!



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] [Pharo 9.0] Build #551: merge-newtools-0.4.2

[Sean P. DeNigris]

ci-pharo-ci-jenkins2 wrote
> Issue Url: https://github.com/pharo-project/pharo/issues/merge

Issue URL is pointing to the wrong place...



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] what is newFrom:

[Sean P. DeNigris]

Stéphane Ducasse wrote
> I’m spotting real inconsistency in the specification and use of newFrom: 

I recently thought something similar when working with ArrayedCollection. As
you say, here is yet another inconsistency because it doesn't return a
"similar object", but just copies the elements of the collection argument
into an instance of itself with the same size. There is also
ArrayedCollection class >> #withAll: which seems to do the same, but neither
delegates to the other and they have different implementations.



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Parsing and navigating Html

[Sean P. DeNigris]

Stéphane Ducasse wrote
> Now a question, I tried to write a comment for and I was wondering why not
> returning '' instead of nil in string.

Ten years after your question, I stumbled upon a SO answer [1] that seems to
explain this behavior. Apparently `string` returns a string-like object
*that retains tree navigation ability* e.g. sibling, parent, where `text`
returns a bare string. From this perspective, `nil` seems appropriate to
indicate that such a navigable object was not available. That said, it
certainly can make the library harder to deal with. What about a Null Object
Pattern that returns an object polymorphic with SoupString and that
implements appropriate no-ops?

1. https://stackoverflow.com/a/25328374



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

[Pharo-dev] Halos Broken - P9 Headless

[Sean P. DeNigris]

Morphic halos don't seem to be working with the Pharo 9 headless VM. They
seem fine with headful. Where do I report this? Pharo or VM repo (or
elsewhere)?



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

[Pharo-dev] Completion Setting Split-Up

[Sean P. DeNigris]

Why has NECPreferences `#spaceAfterCompletion` been moved to NECEntry in
Pharo 9? Usability seems a bit worse because the user now has to know about
two objects to configure it. Also, it was originally held in a class-side
instVar, which made it seem like different NECEntry subclasses might have
different behavior and might justify the move, but it is now a class var,
shared by all, and so the behavior seems the same...



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

[Pharo-dev] Trait Change in Pharo 9?

[Sean P. DeNigris]

In Pharo 9, the following fails to load:

Metacello new
baseline: 'Magritte';
repository: 'github://seandenigris/Magritte';
load: 'Magritte-Bootstrap'.

Specifically, this method fails to compile:
TMagritteBootstrap >> doesNotUnderstand: aMessage
 
^ self magritteDescription 
detect: [ :d | d accessor handlesSelector: aMessage 
selector ]
ifFound: [ :handler | handler handleMessage: aMessage 
for: self ]
ifNone: [ super doesNotUnderstand: aMessage ].

But instead signals that `send: #doesNotUnderstand: toSuperOf:
TMagritteBootstrap` is “not supported”. There is a comment which is over my
head: “Trait methods are copied to the users and only the last literal is
updated. For directed super send the literal of the super send should be
updated too.” 

I feel like this was working previously and would like to understand why
it’s not now and how to fix it.



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] [Pharo 9.0] Build #346: [Doc]: Reflectivity - Metalink Argument and Reification Comments

[Sean P. DeNigris]

ci-pharo-ci-jenkins2 wrote
> The Pull Request #6525 was integrated

Less than 5 hours from Discord question to fix integration - not a bad
turnaround ha ha! From PR submission to merge was less than 2 hours :)



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] [Mm10s] 2020-06-08

[Sean P. DeNigris]

teso...@gmail.com wrote
> - Missing parts in the Image to have Sista + FullBlockClosure.

Yay! Thanks :)



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] [Pharo 9.0] Build #345: add-missing-method-uffi

[Sean P. DeNigris]

ci-pharo-ci-jenkins2 wrote
> Issue Url: https://github.com/pharo-project/pharo/issues/add

The issue link in this report seems to be broken



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Discoverability

[Sean P. DeNigris]

Sean P. DeNigris wrote
> Fixed

https://github.com/pharo-project/pharo/pull/6493



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Discoverability

[Sean P. DeNigris]

Sean P. DeNigris wrote
> the icons and arrows themselves are not properly indented (they are all in
> one vertical
> line regardless of depth in tree) :/

Fixed: `displayMainColumnBy: [ :cell :item | cell useFullIndentation... ]`





-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Discoverability

[Sean P. DeNigris]

Denis Kudriashov wrote
> Try to replace... with...

Thanks!! That added tree node arrows to the class tree :) but the icons and
arrows themselves are not properly indented (they are all in one vertical
line regardless of depth in tree) :/

BTW am I alone in thinking that the class list should be treated as a tree
by default? It basically is a tree *already*, but without the ability to
collapse/expand which limits understanding a large tree where siblings may
be far apart when it's fully expanded.

Also, I can't imagine ever coming up with all that on my own, so I'm glad I
asked, but I'm worried about the future extensibility/maintenance if
original authors aren't available :/


Denis Kudriashov wrote
> You were in the right direction. But there is a little detail here.
> By default your code would work for domain objects in the list (not a
> class
> view).
> But the problem with classes and methods lists is to support the Ring
> model
> where classes are not instances of Class and methods are not instances of
> CompiledMethod.
> My solution was to have a data type for query items. By default it is an
> actual class of objects. But for classes and methods I introduced
> ClyClass and ClyMethod to address the Ring case.
> 
> So try following in your experiment
>ClyClass -> #prepareProjectItemsQueryFrom:in:
> And you should have a debugger.
> 
> I wonder, did you try a halt in #treeStructure users . I think it would
> help to discover this logic.

I checked for senders of #treeStructure (there were none) and then
references to the underlying inst var, but for some reason my eyes glossed
over `queryToExpand:ifAbsent:` and I only ran across it much later in a
debugger, but I don't remember from what route. Although, given your
solution above, is this even necessary?




-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

[Pharo-dev] Discoverability

[Sean P. DeNigris]

I had a "simple" goal: to change Calypso's class pane to a tree. After an
hour or two, I didn't feel any closer! 

I'm wondering if it's my process or something else. A few questions:

1. Is there a heuristic for finding relevant documentation? We have lots of
docs, but there seem to be a lot of separate locations for it. I think I
searched on the Nabble ML mirror for "Calypso" posts on either Pharo list.
After digging around, I found a discussion where Steph was working on a []
booklet, which I read and was helpful for understanding the model but didn't
directly address my issue (not that it should, this is pretty low-level
hacking!). Then I tackled the class comments, which are VERY thorough, but
it's hard (at least for me) to piece together the overall design from the
individual parts.

2. How do we make sophisticated designs discoverable? I remember one of my
Aha! moments when I discovered Smalltalk was using Morphic halos on a menu
item and easily finding the code it used underneath. Things like that do not
generally seem possible anymore in my experience. I thought to myself,
packages are already in a tree, let me dig there! I got a bit worried when I
saw what seemed to be a mini-DSL for tree making instead of simple message
sends:
ClyFullBrowser >> #newPackageView
...
treeStructure:  { 
ClyProjectChildItem -> 
#prepareProjectItemsQueryFrom:in:.
RPackage -> #prepareClassGroupQueryFrom:in: };
But I pressed on and tried to duplicate that logic:
ClyFullBrowser >> #newClassView
...
^ self newNavigationView
treeStructure:  { 
Class -> #prepareProjectItemsQueryFrom:in: }
...

And... nothing. When #prepareClassItemsQueryFrom:in: didn't exist, I got no
debugger. When I created it, placing a halt in it never got triggered.

Besides my immediate experiment of making the class pane a tree, my more
fundamental questions are: 
1. What is the best heuristic to explore the system? This would be great to
put somewhere publicly. Especially, but as we can see from this post not
exclusively, for new users.
2. Do we value discoverability?
3. If so, are we designing our system with this value in mind?



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] uFFI: What is the difference between FFIExternalObject and FFIOpaqueObject?

[Sean P. DeNigris]

Esteban Lorenzano wrote
> The easiest way I have to explain is: 
> 
> You use an OpaqueObject when you will refer to the opaque type in calls
> as:  someFunction(opaqueobject *someArg).
> You use an ExternalObject when you will refer to the opaque type in calls
> as: someFunction(externalobject someArg).

Very clear! We're getting somewhere :) But...

What if a type is used both ways? 

For example:
^ self ffiCall: #(Method * class_copyMethodList(Class self, uint
*outCount))
and
^ self ffiCall: #(struct objc_method_description *
method_getDescription(Method self))



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] uFFI: What is the difference between FFIExternalObject and FFIOpaqueObject?

[Sean P. DeNigris]

Esteban Lorenzano wrote
> The class comments are not clear?

Maybe it's me ;-)


Esteban Lorenzano wrote
> Opaque object = https://en.wikipedia.org/wiki/Opaque_data_type
> ;
> External object = a pointer to something. 

For example, why is ObjCClass a subclass of FFIExternalObject instead of
FFIOpaqueObject when the docs say that a "Class [is] An opaque type that
represents an Objective-C class"? Also, is the distinction just conceptual?
I don't see what either class "buys" you in behavior since they are siblings
that both pretty much have no methods.



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

[Pharo-dev] uFFI: What is the difference between FFIExternalObject and FFIOpaqueObject?

[Sean P. DeNigris]

I'm working on improving the documentation. I'd like examples of situations
when you'd use one or the other and why...

Also, the FFIOpaqueObject class comment could be fleshed out a bit. Check
out this excerpt: 
"this means we always access them through a reference. 
Now, we could declare the pointer to the structures, but 
then our declarations wouldn't be as close to C as we want." 

What would be an example of "declar[ing] the pointer to the structures" and
the resulting declarations that "wouldn't be as close to C as we want"?



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] FullBlockClosure - How to create one...

[Sean P. DeNigris]

Eliot Miranda-2 wrote
> Does Pharo support the Sista bytecodeset yet?  If not, then no full
> blocks.

I guess I will have to be patient then because I see:
- TODO: "[Pharo9] Propose a PR for Fuel to support Sista"[1]
- WIP (reported 2019-12-16): "Detecting all the requirements to use the
Sista bytecode in the 
default image. This modification requires some changes in Fuel. There 
is a need for more changes in the debugger if we want to integrate 
full block closures." [2]


1. http://forum.world.st/Mm10s-2020-03-16-tp5113400p5113415.html
2. http://forum.world.st/Mm10s-2019-12-16-tp5108221p5108298.html




-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] FullBlockClosure - How to create one...

[Sean P. DeNigris]

Eliot Miranda-2 wrote
> (FullBlockClosure receiver: nil outerContext: nil method: blockMethod
> copiedValues: nil) value: 1 value: 2

Cool! We're getting closer, but in Pharo8 FullBlockClosure DNU
#receiver:outerContext:method:copiedValues:

I tried to adapt it to Pharo's API, but the following crashes the VM:
blockMethod := [:a :b| a < b] method.
(FullBlockClosure outerContext: nil startpc: nil numArgs: 2 copiedValues:
nil)
compiledBlock: blockMethod; value: 1 value: 2



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] FullBlockClosure - How to create one...

[Sean P. DeNigris]

Max Leske wrote
> You *need* an outer context.

This is the very point of my experimentation! Why? It wreaks havoc on naive
Fuel users when serialized blocks can't be materialized. In the case of
clean blocks, the outer context is irrelevant from the user perspective.
What I'm trying to figure out is where this requirement comes from and
whether it can be removed, at least for clean blocks.

This seems to be the raison d'être of FullBlockClosure. It's class comment:

A FullBlockClosure is a closure that can be independent of any
outerContext if desired.  It
has its own method (currently reusing the startpc inst var) and its own
receiver.
outerContext can be either a MethodContext/Context or nil.

Unfortunately, I'm having trouble creating one to play with. It seems that
maybe the FullBlockClosure concept is a bit unfinished? I ask this both
because BlockClosure still exists in addition to FullBlockClosure (IIUC I
thought the Full one was a replacement) and because I found the following
posts which talk about future work e.g. for clean blocks:
- https://clementbera.wordpress.com/2016/06/27/fullblockclosure-design/
-
https://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2016-September/124161.html
- (More about Sista) http://wiki.squeak.org/squeak/6589
- (general FullBlock... description) http://wiki.squeak.org/squeak/6610



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

[Pharo-dev] FullBlockClosure - How to create one...

[Sean P. DeNigris]

What am I not understanding about FullBlockClosure?

I have a clean block that I'd like to turn into a FullBlockClosure so that I
can serialize it without dragging (unneeded methods) into my object graph.
However, documentation and in-image example usages seem severely limited.
Here was one experiment that ended with a primitive failure. It seems like a
receiver is needed and it can't be a dummy value (see commented "receiver:
1"). But what would the receiver be in the absence of an outer context?!

aBlockClosure := [ :a :b  | 1 + a + b ].
fbc := (FullBlockClosure
outerContext: nil
startpc: aBlockClosure startpc
numArgs: aBlockClosure argumentCount
copiedValues: Array new) "receiver: 1; yourself".

fbc value: 2 value: 3. "PrimitiveFailed: primitive #value:value: in
FullBlockClosure failed"



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] [Ann] Concurrent Programming in Pharo is available

[Sean P. DeNigris]

Thanks! And thanks in general for your tireless documentation efforts. I know
it can be a lonely pursuit but is s important :)



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

[Pharo-dev] Extending a Class by adding an Instance Variable

[Sean P. DeNigris]

SmalltalkVimMode adds an instance variable to RubSmalltalkEditor so it can
track whether it is in normal/insert mode, etc. Currently, the inst var is
undeclared when the project is loaded and one has to manually edit the class
def to add it.

Is there an elegant way to handle this? I can't think of a way that isn't
awkward, dirtying packages, or leaving zombie objects around when editors
close...



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] URGENT: Pharo 8 Needs Stable Version Update

[Sean P. DeNigris]

EstebanLM wrote
> Done 

I see the new 8.0.1 release tag, but the URL still downloads 8.0.0
(bbcdf97). Is there another step?



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

[Pharo-dev] URGENT: Pharo 8 Needs Stable Version Update

[Sean P. DeNigris]

How do we update https://files.pharo.org/image/80/stable-64.zip?

The "emergency evaluator on warning" issue [1] is fixed, but Launcher is
still serving a pre-fix image under "Official distributions". This seems
like a critical issue as new users may be immediately put off. FYI as a
workaround select the latest snapshot from the "Pharo 8.0" build templates
further down in the tree.

1. https://github.com/pharo-project/pharo/issues/5545



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

[Pharo-dev] Reddit Request: Bootstrap Example/Tutorial

[Sean P. DeNigris]

>> Deployment - it is now possible to bootstrap an image containing exactly
what you want
> Where can I see examples of how to do that? (Genuine question)

I replied with http://forum.world.st/Pharo-Bootstrap-tt5080441.html, but
maybe there's something better?



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Bug report from HN: Windows - "Unsupported 16-bit Application"

[Sean P. DeNigris]

Update from the OP:

Brand new windows 10 system that had never had any Pharo content on it
previously.
Downloaded the launcher pharo-launcher-1.9.2.msi for Windows 64 bit.
Ran it. Launcher shortcut does appear on desktop. So far so good. Double
click Launcher on desktop. Launcher opens, New Image Templates tree-control
populates.
Expand the Official Distributions section and clicked Pharo 9.0 - 64 bit
(development). Right click. Click orange star-icon "Create Image" in the
context menu.
HTTP Progress: Transferring ... xx% appears as I think it should.
After the 100% transfer, the Current images list is no longer empty.
Try to launch and this error appears:
Unsupported 16-Bit Application

The program or feature "\??\C:\Users\x\Documents\Pharo\vms\90-x64\Pharo.exe"
cannot start or run due to incompatibity with 64-bit versions of Windows.
Please contact the software vendor to ask if a 64-bit Windows compatible
version is available.
To confirm, I have gone to the specified location and using a powershell
cmdlet I know of to tell me whether an exe or dll is 32 bit or 64 bit:
PS C:\users\X\Documents\Pharo\vms\90-x64> lsbit .\Pharo.exe WARNING:
C:\users\X\Documents\Pharo\vms\90-x64\Pharo.exe is 16-bit or is not a
Windows executable.
The pharo.exe has md5sum aca3c3eb0523f704d0e60dad9802bf6d and is 2,800,018
bytes in size.
A valid working 64 bit windows pharo.exe I just downloaded from the pharo
home page directly, has md5sum 8dd1289fc38b612530222a231ff6b5c9 and is
2,799,952 bytes in size. The sizes are very similar, but the files are not
binary identical.
The launcher appears to be downloading the wrong thing, or the assets it
fetched are bad.
The lsbit commandlet I am using above is based on the Get-ExeTargetMachine
cmdlet described HERE:
https://etechgoodness.wordpress.com/2014/12/11/powershell-determine-if-an-exe-is-32-or-64-bit-and-other-tricks/



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Fed up

[Sean P. DeNigris]

ducasse wrote
> in Pharo we should write  
>   aCol do: [ :each | each store ]

I always enjoyed the Symbol/Block polymorphism because I thought it was such
a clever and visible example of the power of Smalltalk, and, let's face it,
I'm lazy and enjoyed saving a few key strokes! 

That said, I had no idea that there was a dramatic performance cost. Also,
the issues you raise about analysis seem important.

Since people are free to still use it in their own projects, it doesn't seem
to controversial. Can/should we add a lint rule? Can/should it be scoped to
Pharo core?



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

[Pharo-dev] Bug report from HN: Windows - "Unsupported 16-bit Application"

[Sean P. DeNigris]

Quote: vm doesn't start on Windows - "Unsupported 16-bit Application"... I
resolved the issue by navigating to the directory where it downloaded the
vm's, deleting the folder and unzipping manually. Seems the launcher
corrupts the files when it unzips them.

https://news.ycombinator.com/item?id=22100514



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] [ANN] Pharo 8.0 Released!

[Sean P. DeNigris]

EstebanLM wrote
> Links to upvote: 

These seem to be far and away the most interesting, least
dismissive/abusive, such threads in my memory. They are filled with
thoughtful questions, random defenders, and other nice surprises ;-)



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Short Survey about automatic deprecation rewrites

[Sean P. DeNigris]

Guillermo Polito wrote
> It will be super useful for us to enhance the support for migrations.
> We estimate it will take ~< 3 minutes to fill.

Done! Thanks for setting this up :) I can confirm the time estimate and also
I found the questions relevant.



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Iceberg Bug? Branches with $/

[Sean P. DeNigris]

Ben Coman wrote
> I find slashes in branch names problematic

Okay, you've convinced me. How do we guide people toward that policy? A
warning when creating such branches? At minimum we should change the ghost
text from Iceberg's branch creation dialog, which suggests "feature/what" as
a branch template!



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

[Pharo-dev] GitHub Organizations 1...*Infinity

[Sean P. DeNigris]

It seems we have a new Pharo GH organization every day!

There is for example (pharo-project, pharo-vcs, pharo-rdbms...). The problem
is that each of these creates another entry point that must be known to
users, and therefore another list for us to manually maintain, and we know
the struggle of keeping docs in sync quite well.

My question is: why can't we consolidate into a few general buckets (like
one for official and one for community) and manage the categorization with
GH topics (a.k.a. tags) and teams? Here's a discussion of this idea:
https://github.community/t5/How-to-use-Git-and-GitHub/Structuring-repositories-or-organisations/td-p/5799

IIUC you can use teams to scope the access for each repo. With topics/tags,
someone could just go to the one organization and search for vcs or rdbms to
see a list of just those repos. Here's an example of a saved search like
that: https://github.com/atom/?utf8=✓&q=topic%3Apackage&type=&language=





-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

[Pharo-dev] Iceberg: Why create branch when Reviewing a PR?

[Sean P. DeNigris]

When reviewing a pull request, when merging, why does Iceberg prepend the
repo name to the branch? It seems to require one to manually checkout the
issue branch (and remember not to checkout any packages) in order to modify
the code, no?



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

[Pharo-dev] Iceberg Bug? Branches with $/

[Sean P. DeNigris]

As per common Git workflow, I named an issue branch "port/mac-pharo-7". When
trying to load via: 
Metacello new
baseline: 'VLC';
repository: 'github://seandenigris/Pharo-LibVLC:port/mac-pharo-7';
onConflict: [ :ex | ex allow ];
load.

I got: NotFound: Revspec 'port' not found.. 

Bug?



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] about signal

[Sean P. DeNigris]

ducasse wrote
> It was so simple that I preferred to do it myself so like that I will look
> like a great Pharo contributor. 

:)



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] [Mm10s] 2020-01-06

[Sean P. DeNigris]

ducasse wrote
> The idea is how to fight the combinatory explosion of parameters

Cool!!!



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] [ANN] Sysmel, another experimental low-level language implemented in Pharo

[Sean P. DeNigris]

Ronie Salgado wrote
> In a farther future, a higher performance
> version of the Woden Engine will be made by using Sysmel, mostly because
> it
> seems to be much easier to support real multi-threading in Sysmel by
> making
> a completely new system.

Congrats! But... sad that Pharo may eventually lose Woden. Is there no other
way? E.g. optimizing? Also, do you think "yet another programming language"
to learn will discourage a wide audience for Woden?



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Little challenge

[Sean P. DeNigris]

ducasse wrote
> it looks like a real plague. 

What is the real effect on performance? There is a cost to the complexity of
e.g. caching too, no?



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Happy new year!

[Sean P. DeNigris]

NorbertHartl wrote
> Big thanks to the community, Inria and the consortium for making always
> big success. So I wish everyone a happy new year.

+1 to all!


NorbertHartl wrote
> For me personally 2020 will be a year where most of my work will be
> dedicated to pharo.

Wow! That's great news :)




-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] [Mm10s] 2019-11-25

[Sean P. DeNigris]

ducasse wrote
> Thanks Esteban this is great

Yes, thanks! Very interesting and helpful :)



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] [ANN] Roadmap progress report October 2019 - Open meeting 14/11 16h EU

[Sean P. DeNigris]

EstebanLM wrote
> This is the log of what we have been working on last month. 

Wow, that's quite a list! Some of those have been on the wishlist for a
lng time. Thanks and keep it up :)



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] ZnBufferedReadWriteStream vs SourceFileBufferedReadWriteStream/SourceFileCharacterReadWriteStream

[Sean P. DeNigris]

Sven Van Caekenberghe-2 wrote
> it would be the following change

This seems to be non-backward compatible (e.g. removal of `FileReference >>
binaryReadWriteStream`). That doesn't seem like a good idea on a released
stable version with a new version due for release in months.



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

[Pharo-dev] BlockClosures - Equality and Things

[Sean P. DeNigris]

While developing Magritte, I have a problem because blocks that are
read/written to/from strings (e.g. via Magritte forms) have a different
outerContext before and after and thus I don't know how (without an ugly
hack) to determine whether they were changed by the user.

Question: Is there a smarter way to do block equality?
Currently in Pharo block comparison is via #==. In Squeak, there is:
BlockClosure >> #= aClosure 
self == aClosure ifTrue: [^true]. 
aClosure class = self class ifFalse: [^false]. 
(self method == aClosure method and: [startpc = aClosure startpc
and: [self 
isClean]]) "<--- this line" 
ifTrue: [^true]. 
^outerContext = aClosure outerContext and: [startpc = aClosure
startpc]

I'm not totally sold on the implementation due to the `startpc = aClosure
startpc` the first time it appears (in the comment-marked line). With it, in
a workspace, the following is false: `[1] = [1]`, but removing that test
makes it true. I'd like something that returns true if both blocks are clean
and they "do the same thing". But I like the track it's on...



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Seg Fault Pharo 7.0.3

[Sean P. DeNigris]

Sven Van Caekenberghe-2 wrote
> Are you using full screen mode ?

The window was probably maximized, but not in fullscreen



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Seg Fault Pharo 7.0.3

[Sean P. DeNigris]

Also, the image is sometimes crashing when my MacBook goes to sleep. Not sure
if it's related because there is no crash amp



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] [Pharo 8.0] Build #827: 2442-Commander-should-not-use-Smalltalk-ui-icons-but-self-iconNamed

[Sean P. DeNigris]

ducasse wrote
> The idea is to... 

Thanks for the explanation :)



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] [Pharo 8.0] Build #827: 2442-Commander-should-not-use-Smalltalk-ui-icons-but-self-iconNamed

[Sean P. DeNigris]

ci-pharo-ci-jenkins2 wrote
> "2442-Commander-should-not-use-Smalltalk-ui-icons-but-self-iconNamed"

I was surprised to see `Object>>#iconNamed:`. While it certainly reduces the
duplication of `Smalltalk ui icons`, we have seemed extremely reluctant in
the past to add to Object's inevitable bloat. I'm curious what made this one
in particular worth it?



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

[Pharo-dev] Seg Fault Pharo 7.0.3

[Sean P. DeNigris]

Segmentation fault Thu Oct  3 15:52:33 2019


VM: 201901051900 https://github.com/OpenSmalltalk/opensmalltalk-vm.git
Date: Sat Jan 5 20:00:11 2019 CommitHash: 7a3c6b6
Plugins: 201901051900 https://github.com/OpenSmalltalk/opensmalltalk-vm.git

C stack backtrace & registers:
rax 0x00012438 rbx 0x7ffeebd00050 rcx 0x00468260 rdx
0x00dd6800
rdi 0x000124cee5a0 rsi 0x000124cee5a0 rbp 0x7ffeebcffe50 rsp
0x7ffeebcffe50
r8  0x7fff3f2cefe5 r9  0x0b00 r10 0x6000 r11
0xfcd8d5a0
r12 0x0002 r13 0x3580 r14 0x7ffeebd00064 r15
0x2800
rip 0x7fff630f7d09
0   libsystem_platform.dylib0x7fff630f7d09
_platform_memmove$VARIANT$Haswell + 41
1   Pharo   0x000103f52642 reportStackState
+ 952
2   Pharo   0x000103f52987 sigsegv + 174
3   libsystem_platform.dylib0x7fff630fab3d _sigtramp + 29
4   ??? 0x05890a00 0x0 +
6085968660992
5   libGLImage.dylib0x7fff3f2ce29e
glgProcessPixelsWithProcessor + 2149
6   AMDRadeonX5000GLDriver  0x00010db16db1 glrATIStoreLevels
+ 1600
7   AMDRadeonX5000GLDriver  0x00010db52c83
glrAMD_GFX9_LoadSysTextureStandard + 45
8   AMDRadeonX5000GLDriver  0x00010db519bb glrUpdateTexture
+ 1346
9   libGPUSupportMercury.dylib  0x7fff5181279d
gpusLoadCurrentTextures + 591
10  AMDRadeonX5000GLDriver  0x00010db5a099 gldUpdateDispatch
+ 397
11  GLEngine0x7fff3ff72078
gleDoDrawDispatchCore + 629
12  GLEngine0x7fff3ff16369
glDrawArraysInstanced_STD_Exec + 264
13  GLEngine0x7fff3ff1625a
glDrawArrays_UnpackThread + 40
14  GLEngine0x7fff3ff6dce1 gleCmdProcessor +
77
15  libdispatch.dylib   0x7fff62ec2dcf
_dispatch_client_callout + 8
16  libdispatch.dylib   0x7fff62ecea2c
_dispatch_lane_barrier_sync_invoke_and_complete + 60
17  GLEngine0x7fff3fec4b85
glFlush_ExecThread + 15
18  Pharo   0x000103f4cc62
-[sqSqueakOSXOpenGLView drawRect:flush:] + 314
19  Pharo   0x000103f4cb22 -
...

Smalltalk stack dump:
0x7ffeebd14238 M DelaySemaphoreScheduler>unscheduleAtTimingPriority
0x10fab3ad0: a(n) DelaySemaphoreScheduler
0x7ffeebd14270 M [] in
DelaySemaphoreScheduler(DelayBasicScheduler)>runBackendLoopAtTimingPriority
0x10fab3ad0: a(n) DelaySemaphoreScheduler
   0x1125923f8 s BlockClosure>ensure:
   0x111e88d30 s
DelaySemaphoreScheduler(DelayBasicScheduler)>runBackendLoopAtTimingPriority
   0x112590a50 s [] in
DelaySemaphoreScheduler(DelayBasicScheduler)>startTimerEventLoopPriority:
   0x111e88e08 s [] in BlockClosure>newProcess

Most recent primitives
@
actualScreenSize
millisecondClockValue
tempAt:



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Fuel Not Serializing Stateful Traits

[Sean P. DeNigris]

Marcus Denker-4 wrote
> we coud back port the fix...

That would be great if you think it's fairly safe. Although personally I
could roll back my stateful traits use until P8 since I just started using
them. BTW what is the ETA for P8 release?



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Fuel Not Serializing Stateful Traits

[Sean P. DeNigris]

Sean P. DeNigris wrote
> I see commit 1dd... back in March 2018 says it should work

Investigating a bit further, maybe the problem is in Pharo, because another
test in Pharo 8 didn't show the issue. instanceVariableNamesDo: doesn't seem
to have changed, so I guess it's deeper. Any ideas? Otherwise I'll have to
rollback my stateful trait usage until Pharo 8!



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Difficulty to use Iceberg

[Sean P. DeNigris]

Jan Vrany wrote
> What is the correct workflow to end up with:
> --- A --- B --- C --- D --- E

Not in front of an image, but IIU/RC if you’re seeing “detached”, click
repair, then the option where you use the repository version (which I think
I the last one), then - if the outside changes didn’t effect the Smalltalk
code - from the drop down choose “don’t check anything out” which is
confusing but means that it won’t try to reload any packages in Pharo.  The
result of those steps should be that Pharo recognizes the latest commit. Let
me know whether it works and I’ll be more exact when I get in front of a
computer



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

[Pharo-dev] Fuel Not Serializing Stateful Traits

[Sean P. DeNigris]

Pharo 7.0.3. Fuel 3.0.0 loaded per readme via:
Metacello new
repository: 'github://theseion/Fuel:3.0.0/repository';
baseline: 'Fuel';
load. "Also tried loading : #('CoreWithExtras')"

I see commit 1dd... back in March 2018 says it should work, but I'm
consistently getting the following error:
Array(Object)>>errorSubscriptBounds:
Array(Object)>>at:
SpdClass class(ClassDescription)>>instanceVariableNamesDo:
FLVariablesMapping>>instanceVariableNamesToSerialize
FLVariablesMapping>>initializeAnalyzing
FLVariablesMapping class>>newAnalyzing:references:




-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Iceberg Error in Pharo 7

[Sean P. DeNigris]

Sean P. DeNigris wrote
> somehow the PackageSet got out of sync 

This was also the cause of the problem I reported on Discord where changes
were not showing up in Iceberg.

I create an issue: 
RPackageSet Out of Sync
https://github.com/pharo-project/pharo/issues/4648



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Iceberg Error in Pharo 7

[Sean P. DeNigris]

Sean P. DeNigris wrote
> UndefinedObject(Object)>>doesNotUnderstand: #methodClass
> RGMethodDefinition>>asMCMethodDefinitionFromActiveDefinition

This happened to me again in a different image, but this time with a
different cause. I removed some methods via Calypso and somehow the
PackageSet got out of sync and still listed the non-existent methods. 

The workaround to be able to keep working was to click back to
`#basicSnapshot` in the debugger call chain, "debug it" on `rPackageSet
methods`, and then manually re-evaluate the lazy initialization block.



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

[Pharo-dev] Iceberg Error in Pharo 7

[Sean P. DeNigris]

When trying to convert Soup to Tonel, I got:

UndefinedObject(Object)>>doesNotUnderstand: #methodClass
RGMethodDefinition>>asMCMethodDefinitionFromActiveDefinition
RGMethodDefinition>>basicAsMCMethodDefinition
RGMethodDefinition>>asMCMethodDefinition
[ :ea | definitions add: ea asMCMethodDefinition ] in
MCPackage>>basicSnapshot in Block: [ :ea | definitions add: ea
asMCMethodDefinition ]...etc...
Array(SequenceableCollection)>>do:
MCPackage>>basicSnapshot
IceWorkingCopy>>snapshotForPackage:
IceMCPackageImporter>>snapshot

Ideas?



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Migrating XML support to github/PharoContributions/

[Sean P. DeNigris]

monty-3 wrote
> I will move it to github, if that makes things easier for everyone else.

Hi! Was this ever done? I couldn't find it on GH but maybe I'm looking in
the wrong place...



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Fund rising for the new Spec20 book.

[Sean P. DeNigris]

ducasse wrote
> Thanks and sorry for the burden.

No problem at all.


ducasse wrote
> Could you tell me your bank and I can ask the platform?

Chase



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Launcher: Missing version file for older Pharo

[Sean P. DeNigris]

ducasse wrote
> Can you open a bug entry

Sure. For Launcher?



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Fund rising for the new Spec20 book.

[Sean P. DeNigris]

The site said that my bank refused the transaction. I tried on two cards.
Does it work internationally? Is there another way to send the money?



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Epicea Feedback

[Sean P. DeNigris]

Done:
https://github.com/pharo-project/pharo/issues/4496
https://github.com/pharo-project/pharo/issues/4495



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

[Pharo-dev] Launcher: Missing version file for older Pharo

[Sean P. DeNigris]

Would it be possible to add a pharo.version file to the zip for older (<5.0)
Pharos? 

Right now, Launcher can't determine the version and the file has to be
created manually. Since those versions aren't getting updated, I would
assume it's a one-time task. I didn't file a Launcher issue because I guess
it's an issue with the file server, not with Launcher per se.



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Epicea Feedback

[Sean P. DeNigris]

In case it helps anyone in the future, here is the "poor man's" browser I
hacked together to find all Magritte changes that needed to be rescued from
an image where those changes got out-of-sync so I couldn't use Iceberg:

nodes := EpFileLogNode fromAllLogsIn: EpMonitor current sessionStore
baseLocator.
relevantNodes := nodes reject: [ :n | (n globalName endsWith: 'g3') or: [ n
globalName endsWith: 'ng' ] ].
relevantNodes do: [ :node | node populateReferencedNodesWith: relevantNodes
].
entries := relevantNodes flatCollect: [ :n | n log entries ].
filter := EpAndFilter withAll: {
EpImpactCodeChangeFilter new environment: self class environment; 
yourself.
EpPluggableFilter new condition: [ :e | 
e content isCodeChange and: [ 
e content affectedPackageName beginsWith: 'Magritte' ] 
].
EpPluggableFilter noTriggerFilter }.
filteredEntries := entries select: [ :e | filter accepts: e ].
filteredEntries sort: [ :a :b | (a tagAt: #time) > (b tagAt: #time) ].
groups := filteredEntries groupedBy: [ :e | (e content respondsTo:
#methodAffected) ifFalse: [ '?' ] ifTrue: [ e content methodAffected ] ].
events := groups collect: [ :col | col first content ] as:
OrderedCollection.
events collect: [ :e | "{ e." DiffModel new
showOptions: true;
leftText: (e accept: EpOldStateVisitor new);
rightText: (e accept: EpNewStateVisitor new);
contextClass: e class;
buildWithSpec "}" ].



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

[Pharo-dev] Epicea Feedback

[Sean P. DeNigris]

Not complaining at all and appreciate everyone's hard (mostly-unpaid) work,
but providing raw feedback in case it's helpful...

- Browser awkward: filters disappear whenever left selection changed; no
multi-select of sessions, which led to a host of difficulties described
below.
- What is the heuristic to find API access points? Epicea package has no
comment, 'Browser' tag doesn't seem to have an XyzBrowser class, no
particular class in the 'Model' tag jumps out at me as an access point; as
above Browser about text not set. I finally bring up Morphic halos on the
browser and after flopping around, find subclasses of EpLogNode; I browse it
and find EpLogNodeGraphModel, which sounds interesting and turns out to be a
spec. I figure out how to list the log files, but not how to get the entries
- I was expecting a term like that and the relevant method (#log it turns
out) has no comment to indicate it's what I'm looking for. Now that I'm
starting to understand the project organization, back to the browser to
explore EpUnifiedBrowserModel. After a bit of poking around, I suspect
(correctly) that #log is what I'm after.

Based on code I extract from the browsers and a bit of experimenting in GT,
I come up with the following seemingly very complex script:

nodes := EpFileLogNode fromAllLogsIn: EpMonitor current sessionStore
baseLocator.
nodes do: [ :node | node populateReferencedNodesWith: nodes ].
nodes flatCollect: [ :n | n log events select: [ :e | e affectedPackageName
beginsWith: 'Magritte' ] ]

I now run into a series of problems because, although EpCodeChange declares
#affectedPackageName as an abstract method, not all events are
EpCodeChanges. I exclude EpUndos. Easy enough. Now I come to an
EpGenericRefactoring. This one is harder because 

p.s. Code names for internal projects seem extremely
counterproductive. Hiedra tells me absolutely nothing about functionality.
It might as well be called XyzWidgetThing



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

[Pharo-dev] Two Surprising and Scary FS Behaviors

[Sean P. DeNigris]

I may be ignorant of some key principle in the filesystem world, but IMHO
conceptually, `location / somethingElse` should always return either
location or something inside of it, unless the request explicitly requests
otherwise (e.g. location / '..'). To do otherwise could be disastrous.

Behavior #1
rootDataFolder := FileLocator home / 'a' / 'b' / .
subfolderName := self accidentallyReturnAnEmptyString.
assumedToBeInRootData := rootDataFolder / subfolderName.
assumedToBeInRootData deleteAll. 

"I hope I have a recent machine backup, because..."
assumedToBeInRootData resolve = FileLocator root resolve. "WTH?!"

Behavior 2 (similar)
Path * 'a' / 'b' / '/' = Path root. "WTH?!"



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Pharo Launcher 1.9.2 Crash

[Sean P. DeNigris]

demarey wrote
> Could you test it?

Yes, works now! Thanks :)



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] P8 voyage not installing, error probably in magritte

[Sean P. DeNigris]

Sanjay Minni wrote
> failure is probably in magritte

Can you give more specifics? Where is voyage installing Magritte from?
Active development has recently moved to GH



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] [ANN] Pharo Launcher 1.9.1 released

[Sean P. DeNigris]

demarey wrote
> we want more feedback before promoting it.

"Show in folder" doesn't work - still trying to use OSProcess which appears
to no longer be loaded. BTW IMHO it would be better to create a layer to
hide the process differences on different OSes. This new world of a
different lib for each OS is hopefully a milestone on a path to a more
unified future, and it will be harder to clean out all the "if windows"
conditionals later.



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

[Pharo-dev] Pharo Launcher 1.9.2 Crash

[Sean P. DeNigris]

PharoLauncher-1.9.2-x64.dmg does not open on Mac OS 10.14.1. Crash dump shows
Freetype related:

Segmentation fault Fri Jul 26 09:07:17 2019

VM: 201901051900 https://github.com/OpenSmalltalk/opensmalltalk-vm.git
Date: Sat Jan 5 20:00:11 2019 CommitHash: 7a3c6b6
Plugins: 201901051900 https://github.com/OpenSmalltalk/opensmalltalk-vm.git

C stack backtrace & registers:
rax 0x000111ae3be0 rbx 0x0001121a1878 rcx 0x rdx
0x018c
rdi 0x000111ae3be0 rsi 0x000111ae3be0 rbp 0x7ffee922c1b0 rsp
0x7ffee922c1b0
r8  0x r9  0x r10 0x000106a935a0 r11
0x000111ae3be0
r12 0x r13 0x0010 r14 0x r15
0x
rip 0x7fff67353dd0
0   libsystem_platform.dylib0x7fff67353dd0
_platform_memmove$VARIANT$Haswell + 240
1   Pharo   0x000106a25642 reportStackState
+ 952
2   Pharo   0x000106a25987 sigsegv + 174
3   libsystem_platform.dylib0x7fff67356b3d _sigtramp + 29
4   ??? 0x 0x0 + 0
5   Pharo   0x000106a5e5aa
primitiveCalloutWithArgs + 164

Smalltalk stack dump:
0x7ffee923a2d0 M LibC>memCopy:to:size: 0x10ec722d8: a(n) LibC
0x7ffee923a318 M LibC class>memCopy:to:size: 0x10e4c65e0: a(n) LibC
class
0x7ffee923a380 I ExternalAddress>copyFrom:to: 0x111bab200: a(n)
ExternalAddress
   0x111baea18 s FreeTypeFace(FT2Face)>renderGlyphIntoForm:pixelMode:
   0x111bbc5b8 s FreeTypeFace(FT2Face)>renderGlyphIntoForm:
   0x111bc2db0 s
FreeTypeSubPixelAntiAliasedGlyphRenderer>renderStretchedGlyph:depth:subpixelPosition:font:
   0x111bc6a70 s
FreeTypeSubPixelAntiAliasedGlyphRenderer>subGlyphOf:colorValue:mono:subpixelPosition:font:



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] P8 + aTalent - aKind

[Sean P. DeNigris]

NorbertHartl wrote
> I’m playing again with Talents and I want that in Pharo8 to appear so it
> can mature. 

I'm very interested in this. Adding behavior at runtime only when an object
takes on a role seems to have many possibilities e.g. expressiveness and
code simplification.



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] [Pharo 8.0] Build #412: Making the World to render in different backends

[Sean P. DeNigris]

ci-pharo-ci-jenkins2 wrote
> The Pull Request #3627 was integrated: "Making the World to render in
> different backends"

Sounds cool :)



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] ZLibWriteStream compression level

[Sean P. DeNigris]

I'm not sure, but to help isolate the bug, you could try compressing outside
the image via LibC (easier) or UFFI



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Versioning with Iceberg

[Sean P. DeNigris]

Shaping1 wrote
> that Pharo labels are truncated if you switch to a monospace font

Did you try doing this before opening any windows? There is a problem that
sometimes already-open tools are not properly updated when the font is
changed...



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Dependencies between git projects ?

[Sean P. DeNigris]

Sven Van Caekenberghe-2 wrote
>  is it actually 'wrong' ?

Looks okay to me. Can you say more about what you mean by “wrong”?

NB if your subprojects have metadata and your main project doesn’t have to
be compatible outside recent Pharo you can remove the code subfolder from
those URLs and eliminate a bit of duplication 



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] PR2789, Rubric integration revert

[Sean P. DeNigris]

Tim Mackinnon wrote
> But most of all - we need everyone on board to make needed improvements,
> and keep our environment and community healthy!

Yes!! Written communication is a terrible channel for emotional content.
Unless we all assume that each others' intentions are good, interpret
ambiguous messages generously, and stick to technical issues, we are lost.
We all get frustrated and tempted to dump our feelings onto mailing lists,
but there is nothing to be gained, and a lot to lose.

p.s. Since there seems to be a swell of new interest in Pharo, this also
leaves a bad impression for newbies.



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] How to manage your code with Iceberg

[Sean P. DeNigris]

Stéphane Ducasse wrote
> https://github.com/SquareBracketAssociates/Booklet-ManagingCode 

I submitted a comprehensive grammar pass. I just want to point out that this
was only possible due to the incredible amount of work people have done to
move us into the git/GH world. In the past, my experience was that
submitting a fix often took at least as long as doing the actual fixing (and
significantly longer for small fixes)! 

Past:
1. save the packages individually
2. Publish the code 
  a. if the repo allowed writing, put them there
  b. if read-only, come up with some alternative, like creating your own
monolithic staging area repo, or other DIY solution
  c. if the repo was abandoned, you'd probably be better off giving up and
finding a new profession, because you may end up manually copying the repo
with no API way to establish the link
3. create a mailing list thread for discussion
4. Wait and hope

Present: 
1. Save all project changes in one step
2. Click "Create PR"
Bonus #1: Go have a beer
Bonus #2: you can keep working with your new changes by loading from your
fork until the canonical accepts the PR

So: /thank you/ to everyone involved in git/GH/Iceberg support!!!



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] How to manage your code with Iceberg

[Sean P. DeNigris]

Sean P. DeNigris wrote
> FYI the bin tray link on GH -> “The requested path was not found.”

It's working now.



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] How to manage your code with Iceberg

[Sean P. DeNigris]

Stéphane Ducasse wrote
> I'm happy to announce a new booklet

Cool! FYI the bin tray link on GH -> “The requested path was not found.”



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Esteban's ChangeLog week of 11 March 2019

[Sean P. DeNigris]

EstebanLM wrote
>   addGroup: [ :group |
>   group 
>   addItem: [ :item | item name: 'Something 1'; action: [
> "doSomething"] ];

How would one extend a menu with this approach e.g. add an item to the group
from elsewhere (outside the block)? Is it even possible?



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] OSProcess for Pharo 7

[Sean P. DeNigris]

ducasse wrote
> Our main problem is that 
>   - if more people would review PR
>   - send PRs 

Thank you for the reminder of that bottleneck. I will try to do that more
now that we have moved to GH. The old process seemed too cumbersome to be
able to effectively utilize a few free moments here and there, but I suspect
that no longer to be the case.


ducasse wrote
> this is not because we do not care of Pharo that we will fix it
> immediately. 

Yes of course, just want to keep it on the radar (and maybe Mariano will
read he he)



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] OSProcess for Pharo 7

[Sean P. DeNigris]

Max Leske wrote
>> I was talking about OSSubProcess
> Well, I'm not working with that at the moment ;)

[OT] Just want to bump the problem that OSProcess and OSSubProcess can't
currently be used in the same image. This is an important problem because
users can't control which library dependencies use. Mariano hinted at a
solution. It didn't seem like a ton of work, but it's beyond my
understanding. 



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html