Re: [Pharo-dev] OpenSSL binding Re: About strange email related to smalltalkhub read-only on squeak-dev
On Thu, Jun 04, 2020 at 10:31:09AM +0200, Norbert Hartl wrote: > > Am 04.06.2020 um 02:44 schrieb Pierce Ng : > > On Tue, Jun 02, 2020 at 11:17:30AM +0200, Norbert Hartl wrote: > >> PierceNg has an implementation that implements a subset of openssl. > >> This implementation is modeled after the library so lots of class > >> methods. I'd prefer to have something more object model like. > > > > A very small subset currently, as my original need was to create an X509 > > request in code. PRs welcome. > > > > https://github.com/PierceNg/OpenSSL-Pharo > > > If it is a small subset it might be feasible to talk about the approach > taken. Sure. I don't see too many misplaced class methods myself. I've just loaded the package into a fresh image for a spin. My self-built VM uses OpenSSL 1.1.1 (instead of OpenSSL 1.0.x in the prebuilt VMs) and there are C API changes between those two OpenSSL versions that break many tests, basic things like XXX_create becoming XXX_new, XXX_init becoming XXX_reset etc. So I've created branches openssl_1_1 and openssl_1_0 that will match the versions used by Pharo. Pierce
Re: [Pharo-dev] Discoverability
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 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
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] [Pharo 9.0] Build #340: pushOuterVectors-use-tempVectorVarNames
There is a new Pharo build available! The status of the build #340 was: SUCCESS. The Pull Request #6478 was integrated: "pushOuterVectors-use-tempVectorVarNames" Pull request url: https://github.com/pharo-project/pharo/pull/6478 Issue Url: https://github.com/pharo-project/pharo/issues/pushOuterVectors Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo9.0/340/
[Pharo-dev] [Pharo 8.0] Build #1140: 6418-Backport-5643-into-Pharo8
There is a new Pharo build available! The status of the build #1140 was: SUCCESS. The Pull Request #6429 was integrated: "6418-Backport-5643-into-Pharo8" Pull request url: https://github.com/pharo-project/pharo/pull/6429 Issue Url: https://github.com/pharo-project/pharo/issues/6418 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo8.0/1140/
[Pharo-dev] [Pharo 9.0] Build #339: Created a simple and a complex test for the changes file flushing issue
There is a new Pharo build available! The status of the build #339 was: FAILURE. The Pull Request #6492 was integrated: "Created a simple and a complex test for the changes file flushing issue" Pull request url: https://github.com/pharo-project/pharo/pull/6492 Issue Url: https://github.com/pharo-project/pharo/issues/6491 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo9.0/339/
[Pharo-dev] [Pharo 9.0] Build #338: 6049-It-should-not-be-possible-to-use-super-as-something-else-than-the-receiver-of-a-message
There is a new Pharo build available! The status of the build #338 was: SUCCESS. The Pull Request #6482 was integrated: "6049-It-should-not-be-possible-to-use-super-as-something-else-than-the-receiver-of-a-message" Pull request url: https://github.com/pharo-project/pharo/pull/6482 Issue Url: https://github.com/pharo-project/pharo/issues/6049 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo9.0/338/
Re: [Pharo-dev] Discoverability
Hi Sean.
пт, 5 июн. 2020 г. в 16:15, 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 implemented it in very early stages. But I did have time to implement it
in a better way.
The old code is still there. But I did not expose it to the browser widgets
API.
Try to replace following line in ClyFullBrowser>>switchToFlatClasses
classView showQueries: classQueries as: ClyExtensionLastSortedClasses
hierarchical
with:
fullQuery := ClyQuery unionFrom: classQueries as:
ClyExtensionLastSortedClasses hierarchical.
classView initiateUIChangeBy: [
dataSource := ClyExpandedDataSource on: fullQuery.
classView dataSource: dataSource.
classView ensureSelectedItemIfNeeded].
The trick is to use ClyExpandedDataSource instead of
ClyCollapsedDataSource. The former is responsible to provide expansion to
predefined internal tree structure (which you see in default browser).
I wanted to merge them but I had no time for that.
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: }
>
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.
Denis
...
>
> 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
>
>
[Pharo-dev] Discoverability
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
[Pharo-dev] [Pharo 9.0] Build #337: emitStore-do-not-use-Object-new
There is a new Pharo build available! The status of the build #337 was: FAILURE. The Pull Request #6477 was integrated: "emitStore-do-not-use-Object-new" Pull request url: https://github.com/pharo-project/pharo/pull/6477 Issue Url: https://github.com/pharo-project/pharo/issues/emitStore Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo9.0/337/
Re: [Pharo-dev] question about Zinc ZnUrl or ZnResourceMetaUtils
https://github.com/svenvc/zinc/commit/7a42881f14144e0d9dcc2b3aa98a075f189eae69 > On 4 Jun 2020, at 23:06, Sven Van Caekenberghe wrote: > > Theoretically, the order is not important (should not matter), but for > practical purposes (like being able to parse a URL and print it to the same > representation) it would be a good idea. > > I'll see if I can add it. > >> On 28 May 2020, at 11:24, Stéphane Ducasse wrote: >> >> Hi sven >> >> Are the dictionaries for the query part conserving the order? >> Because this would be really nice. >> >> S. >> >> Stéphane Ducasse >> http://stephane.ducasse.free.fr / http://www.pharo.org >> 03 59 35 87 52 >> Assistant: Aurore Dalle >> FAX 03 59 57 78 50 >> TEL 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 >> >
[Pharo-dev] [Pharo 9.0] Build #336: Fix https://github.com/pharo-vcs/iceberg/issues/1331
There is a new Pharo build available! The status of the build #336 was: FAILURE. The Pull Request #6455 was integrated: "Fix https://github.com/pharo-vcs/iceberg/issues/1331; Pull request url: https://github.com/pharo-project/pharo/pull/6455 Issue Url: https://github.com/pharo-project/pharo/issues/fix/iceberg/1331 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo9.0/336/
[Pharo-dev] [Pharo 9.0] Build #335: Fixing broken dependency test
There is a new Pharo build available! The status of the build #335 was: FAILURE. The Pull Request #6490 was integrated: "Fixing broken dependency test" Pull request url: https://github.com/pharo-project/pharo/pull/6490 Issue Url: https://github.com/pharo-project/pharo/issues/fixing Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo9.0/335/
[Pharo-dev] R: PROPOSAL: UN-St (United Nations of Smalltalk)
Excellent idea! Lorenzo -Messaggio originale- Da: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] Per conto di Sean DeNigris Inviato: giovedì 4 giugno 2020 18:16 A: cuis-...@cuis-smalltalk.org; pharo-dev@lists.pharo.org; squeak-...@lists.squeakfoundation.org Oggetto: [Pharo-dev] PROPOSAL: UN-St (United Nations of Smalltalk) I believe that the Squeak/Pharo/Cuis communit(ies) share one very special thing, which most of the world has completely missed, and which the world sorely needs if the true power of computing to unleash and evolve the human mind is ever to be realized: a love and appreciation for personal technological augmentation/amplification available to all as represented by the Dynabook and/or its prototype software (Smalltalk as a concept, not any version/implementation e.g. Smalltalk-80). Like a few survivors after the sinking of Atlantis, we can pick up the remnants of this dream and resume marching toward the objective (or at least keep its memory alive until an auspicious time when it can be realized)… or, like most groups of human beings throughout history who start with a common aim, we can bicker among ourselves about e.g. historical discrepancies, personal slights, and conflicting subgoals, and allow those squabbles to distract us and derail our primary mission. This would be disappointing but not surprising: it is how every war is started. I have contributed, hacked, conferenced, and visited with many members of our wider community for over a decade now and, maybe because I had the “luxury” of finding Smalltalk after some of the political lines had been well-drawn, I can clearly see that we are fundamentally united. I cringe every time I see cynical, caustic exchanges - both for my participating colleagues who are obviously in pain - probably exacerbated by their passion for our shared endevour - and for the counterproductive effect the antagonism is sure to have on our common goal. Virtually every exchange is between two people who I personally know to be good and competent. Here is my proposal: Let’s form an informal committee - a United Nations of Smalltalk if you will - including at least one member of each community, who will collaborate on cooperation between the dialects and mediate any friction before it boils over. I’d be happy to participate, I guess as a representative of the Pharo community. Although I have no official role in the Pharo leadership, I have much of my professional life invested there. I often wish I had the time to keep all my projects compatible with Squeak, but I usually feel like I’m barely keeping up as it is! I hope I’m not alone in these feelings and look forward to the response of our community (most emphatically singular). This message is being cross-posted to Pharo-Dev, Squeak-Dev, and Cuis MLs (I think I’m still a member of all three - fingers crossed…) - Sean (DeNigris) -- Questa e-mail è stata controllata per individuare virus con Avast antivirus. https://www.avast.com/antivirus
[Pharo-dev] [Pharo 9.0] Build #334: 6415-RBMethodNode-should-have-allComments #6415
There is a new Pharo build available! The status of the build #334 was: SUCCESS. The Pull Request #6484 was integrated: "6415-RBMethodNode-should-have-allComments #6415" Pull request url: https://github.com/pharo-project/pharo/pull/6484 Issue Url: https://github.com/pharo-project/pharo/issues/6415 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo9.0/334/
[Pharo-dev] [Pharo 9.0] Build #333: simplify-firstPrecodeComment
There is a new Pharo build available! The status of the build #333 was: FAILURE. The Pull Request #6483 was integrated: "simplify-firstPrecodeComment" Pull request url: https://github.com/pharo-project/pharo/pull/6483 Issue Url: https://github.com/pharo-project/pharo/issues/simplify Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo9.0/333/
