Hi, there.

> What's wrong with:

That's a message-list browser. An actual browser for flags would also give an overview. So, your example can only work if (1) the user knows what to look for, and (2) the important information is not hidden in a comment besides the flag. :-)

Best,
Marcel
Am 07.04.2020 14:29:57 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:
Hi Marcel,

> We do need a simple #flag-comment browser in Squeak. I suppose. Senders is not enough because we have no overview of the existing flags.

What's wrong with:

self systemNavigation
browseMessageList: (#(flag: needsWork notYetImplemented) gather: [:sel |
self systemNavigation allCallsOn: sel])
name: 'Flag Browser'

Would you like to filter them by flag argument?
I find your work in Vivide about flags very helpful: SystemNavigation >> #allFlagComments and ViLocator >> #searchFlags:.


By the way: The flag selectors are all hard-coded in Behavior >> #toolIconSelector:. Should we use a pragma for this - something like this?

halt
<flag>
"This is the typical message to use for inserting breakpoints during 
debugging. It behaves like halt:, but does not call on halt: in order to 
avoid putting this message on the stack. Halt is especially useful when 
the breakpoint message is an arbitrary one."

Halt signal

Or should we just move the hard-coded list from #toolIconSelector: into a new CompiledMethod >> #hasFlag?

Best,
Christoph


Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel
Gesendet: Montag, 30. März 2020 13:36 Uhr
An: John Pfersich via Squeak-dev
Betreff: Re: [squeak-dev] The Trunk: Compiler-ct.426.mcz
 
Hehe. :-) Maybe browse the image's flag comments to get inspiration on how others write it.

We do need a simple #flag-comment browser in Squeak. I suppose. Senders is not enough because we have no overview of the existing flags. And surrounding comments may be hard to navigate.

self flag: #todo. "mt: Write flags browser."

:-)

Best,
Marcel
Am 30.03.2020 13:33:08 schrieb Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
A sort of negation of:

> Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément.

Nicolas Boileau


Le lun. 30 mars 2020 à 13:25, Marcel Taeumel <marcel.taeumel at hpi.de [mailto:marcel.taeumel at hpi.de]> a écrit :

Hi Nicolas.

> due to hackish nature of this piece of code, it's going to be difficult to find an enlightening comment. Eliot rather suggested a rewrite of this portion.

That's exactly the comment that would help me. Mark it as "under construction" somehow. Use comments and/or #flag:.

Best,
Marcel
Am 30.03.2020 12:32:28 schrieb Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com [mailto:nicolas.cellier.aka.nice at gmail.com]>:
Personnally, I would use a constructor without index and let the Node take care of as yet uninitialized index, rather than leaking the knowledge of nil <=> uninitialized to the client side.


Le lun. 30 mars 2020 à 12:28, Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com [mailto:nicolas.cellier.aka.nice at gmail.com]> a écrit :

Hi Marcel,
due to hackish nature of this piece of code, it's going to be difficult to find an enlightening comment.
Eliot rather suggested a rewrite of this portion.


Le lun. 30 mars 2020 à 12:17, Marcel Taeumel <marcel.taeumel at hpi.de [mailto:marcel.taeumel at hpi.de]> a écrit :

Hi all.

Changing a "0" into a "nil" deserves a comment *in* that changed method. Otherwise, this is meant to be changed back in the future because "0" maybe be more readable than "nil". :-)

Best,
Marcel
Am 28.03.2020 14:32:28 schrieb commits at source.squeak.org [mailto:commits at source.squeak.org] <commits at source.squeak.org [mailto:commits at source.squeak.org]>:
Nicolas Cellier uploaded a new version of Compiler to project The Trunk:
http://source.squeak.org/trunk/Compiler-ct.426.mcz [http://source.squeak.org/trunk/Compiler-ct.426.mcz]

==================== Summary ====================

Name: Compiler-ct.426
Author: ct
Time: 28 March 2020, 1:22:49.51256 am
UUID: 761924e9-77a0-1144-9533-8a7c22c03332
Ancestors: Compiler-ct.424

Fixes a bug regarding decompilation of special selectors.

The following did not work before:

(OrderedCollection >> #asArray) decompile generate valueWithReceiver: {42} asOrderedCollection arguments: #(). "MessageNotUnderstood: OrderedCollection>>#Array=>Array"

See also this thread: http://forum.world.st/The-Inbox-EToys-ct-367-mcz-tp5105507p5114020.html [http://forum.world.st/The-Inbox-EToys-ct-367-mcz-tp5105507p5114020.html]

=============== Diff against Compiler-ct.424 ===============

Item was changed:
----- Method: DecompilerConstructor>>codeAnySelector: (in category 'constructor') -----
codeAnySelector: selector

^SelectorNode new
key: selector
+ index: nil
- index: 0
type: SendType!




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200407/1e075f9b/attachment.html>