The Trunk: Compiler-ct.426.mcz

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

The Trunk: Compiler-ct.426.mcz

commits-2
Nicolas Cellier uploaded a new version of Compiler to project The Trunk:
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

=============== 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!


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Compiler-ct.426.mcz

marcel.taeumel
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 [hidden email] <[hidden email]>:

Nicolas Cellier uploaded a new version of Compiler to project The Trunk:
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

=============== 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!




Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Compiler-ct.426.mcz

Nicolas Cellier
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 <[hidden email]> 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 [hidden email] <[hidden email]>:

Nicolas Cellier uploaded a new version of Compiler to project The Trunk:
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

=============== 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!





Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Compiler-ct.426.mcz

Nicolas Cellier
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 <[hidden email]> 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 <[hidden email]> 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 [hidden email] <[hidden email]>:

Nicolas Cellier uploaded a new version of Compiler to project The Trunk:
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

=============== 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!





Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Compiler-ct.426.mcz

marcel.taeumel
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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]> 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 [hidden email] <[hidden email]>:

Nicolas Cellier uploaded a new version of Compiler to project The Trunk:
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

=============== 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!





Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Compiler-ct.426.mcz

Nicolas Cellier
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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]> 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 [hidden email] <[hidden email]>:

Nicolas Cellier uploaded a new version of Compiler to project The Trunk:
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

=============== 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!






Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Compiler-ct.426.mcz

marcel.taeumel
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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]> 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 [hidden email] <[hidden email]>:

Nicolas Cellier uploaded a new version of Compiler to project The Trunk:
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

=============== 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!






Reply | Threaded
Open this post in threaded view
|

Flag Browser (was: The Trunk: Compiler-ct.426.mcz)

Christoph Thiede

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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]> 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 [hidden email] <[hidden email]>:

Nicolas Cellier uploaded a new version of Compiler to project The Trunk:
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

=============== 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!






Reply | Threaded
Open this post in threaded view
|

Re: Flag Browser (was: The Trunk: Compiler-ct.426.mcz)

marcel.taeumel
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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]> 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 [hidden email] <[hidden email]>:

Nicolas Cellier uploaded a new version of Compiler to project The Trunk:
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

=============== 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!






Reply | Threaded
Open this post in threaded view
|

Re: Flag Browser (was: The Trunk: Compiler-ct.426.mcz)

Christoph Thiede

I see :-)


Hm, maybe it would be interesting if we could decouple the Browser (hierarchical arrangement) from the System Browser (browsing methods by class/category). I could imagine some other usages ... flag browser, AcceptIt, 

basically to browse any grouping of texts ... :-)

Best,
Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Dienstag, 7. April 2020 14:37:47
An: gettimothy via Squeak-dev
Betreff: Re: [squeak-dev] Flag Browser (was: The Trunk: Compiler-ct.426.mcz)
 
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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]> 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 [hidden email] <[hidden email]>:

Nicolas Cellier uploaded a new version of Compiler to project The Trunk:
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

=============== 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!






Reply | Threaded
Open this post in threaded view
|

Re: Flag Browser (was: The Trunk: Compiler-ct.426.mcz)

marcel.taeumel
Hm, maybe it would be interesting if we could decouple the Browser (hierarchical arrangement) from the System Browser..

There are many projects out there, that try to tackle that challenge from different angles. OmniBrowser, Vivide, Whisker browser, StarBrowser, maybe parts of BabyIDE, Nautilus, the tools within the Glamorous Toolkit, ...

In this case, a simple sublcass of CodeHolder would suffice, I suppose. ;-)

Best,
Marcel

Am 07.04.2020 14:47:24 schrieb Thiede, Christoph <[hidden email]>:

I see :-)


Hm, maybe it would be interesting if we could decouple the Browser (hierarchical arrangement) from the System Browser (browsing methods by class/category). I could imagine some other usages ... flag browser, AcceptIt, 

basically to browse any grouping of texts ... :-)

Best,
Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Dienstag, 7. April 2020 14:37:47
An: gettimothy via Squeak-dev
Betreff: Re: [squeak-dev] Flag Browser (was: The Trunk: Compiler-ct.426.mcz)
 
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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]> 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 [hidden email] <[hidden email]>:

Nicolas Cellier uploaded a new version of Compiler to project The Trunk:
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

=============== 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!