Begin forwarded message:Subject: Bounce action notificationDate: 20. September 2017 um 12:23:16 MESZDelivered-To: squeak-dev-owner@mail.squeak.orgThis is a Mailman mailing list bounce action notice:
List: Squeak-dev
Member: otadini@outlook.com
Action: Subscription disabled.
Reason: Excessive or fatal bounces.
The triggering bounce notice is attached below.
Questions? Contact the Mailman site administrator at
mailman@lists.squeakfoundation.org.From: MAILER-DAEMON@mail.squeak.org (Mail Delivery System)Subject: Undelivered Mail Returned to SenderDate: 20. September 2017 um 12:16:47 MESZDelivered-To: squeak-dev-bounces@mail.squeak.org
This is the mail system at host mail.squeak.org.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
<otadini@outlook.com>: host
outlook-com.olc.protection.outlook.com[104.47.46.33] said: 550 5.7.1
Unfortunately, messages from [162.242.237.43] weren't sent. Please contact
your Internet service provider since part of their network is on our block
list (AS3150). You can also refer your provider to
http://mail.live.com/mail/troubleshooting.aspx#errors. (in reply to MAIL
FROM command)
Reporting-MTA: dns; mail.squeak.org
X-Postfix-Queue-ID: B580A14D389
X-Postfix-Sender: rfc822; SRS0=peo+=AT=lists.squeakfoundation.org=squeak-dev-bounces@squeak.org
Arrival-Date: Mon, 18 Sep 2017 12:00:02 +0000 (UTC)
Final-Recipient: rfc822; otadini@outlook.com
Original-Recipient: rfc822;otadini@outlook.com
Action: failed
Status: 5.7.1
Remote-MTA: dns; outlook-com.olc.protection.outlook.com
Diagnostic-Code: smtp; 550 5.7.1 Unfortunately, messages from [162.242.237.43]
weren't sent. Please contact your Internet service provider since part of
their network is on our block list (AS3150). You can also refer your
provider to http://mail.live.com/mail/troubleshooting.aspx#errors.Subject: Squeak-dev Digest, Vol 177, Issue 17Date: 18. September 2017 um 14:00:01 MESZReply-To: squeak-dev@lists.squeakfoundation.org
Send Squeak-dev mailing list submissions to
squeak-dev@lists.squeakfoundation.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-dev
or, via email, send a message with subject or body 'help' to
squeak-dev-request@lists.squeakfoundation.org
You can reach the person managing the list at
squeak-dev-owner@lists.squeakfoundation.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Squeak-dev digest..."
Today's Topics:
1. Re: How should one implement a custom window color for a
custom window? (Stéphane Rollandin)
2. Re: How should one implement a custom window color for a
custom window? (Chris Muller)
3. IPv6 implementation code (Alan Pinch)
4. ASN1 encoding of UTF8 (Alan Pinch)
5. Re: IPv6 implementation code (David T. Lewis)
6. Re: ASN1 encoding of UTF8 (Jakob Reschke)
7. Re: How should one implement a custom window color for a
custom window? (Marcel Taeumel)
8. The Trunk: Tests-mt.382.mcz (commits@source.squeak.org)
9. Re: IPv6 implementation code (Alan Pinch)
10. Re: ASN1 encoding of UTF8 (Alan Pinch)
11. Re: How should one implement a custom window color for a
custom window? (Stéphane Rollandin)
12. Re: How should one implement a custom window color for a
custom window? (Marcel Taeumel)
13. Re: How should one implement a custom window color for a
custom window? (Stéphane Rollandin)
14. Re: How should one implement a custom window color for a
custom window? (Stéphane Rollandin)
15. Re: How should one implement a custom window color for a
custom window? (Marcel Taeumel)
16. Re: How should one implement a custom window color for a
custom window? (Stéphane Rollandin)
17. The Trunk: Tests-mt.382.mcz (commits@source.squeak.org)
18. The Trunk: Tests-mt.383.mcz (commits@source.squeak.org)From: Stéphane Rollandin <lecteur@zogotounga.net>Subject: Re: [squeak-dev] How should one implement a custom window color for a custom window?Date: 17. September 2017 um 14:02:16 MESZTo: "liste [Squeak-dev]" <squeak-dev@lists.squeakfoundation.org>
Nice informative post, thanks Marcel.
I think I see something fragile in the implementation though: each #userInterfaceTheme send must absolutely be followed by another selector, else the relevant stacked object (in the scope inst. var. of the theme) will not be popped at the proper moment.
In other words, a line of code as simple as
Morph new userInterfaceTheme explore
may break things in potentially ugly ways; for one thing, even if further scope push/pop work properly, the Morph instanciated by the above code will never be GCed...
Does that make sense?
StefFrom: Chris Muller <asqueaker@gmail.com>Subject: Re: [squeak-dev] How should one implement a custom window color for a custom window?Date: 18. September 2017 um 02:09:22 MESZTo: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>Reply-To: ma.chris.m@gmail.com
That's true. One goal of the design was to provide access to a
first-class Theme object, without needing to either write, nor see,
that extra level of indirection in the code.
myMorph userInterfaceTheme color
vs.
(myMorph userInterfaceTheme propertyNamed: #color)
The latter becomes a wordy and repetitious (not to mention, the extra
parenthesis), a lot to ask clients to sprinkle throughout their code.
I don't see the example "never being GC'd" as being related to the
UserInterfaceTheme implementation. I may be missing your question but
-- if an explorer is opened [substitute with any case of: user still
needs the object], the object would not be GC'd, regardless from which
code it was opened.
- Chris
On Sun, Sep 17, 2017 at 7:02 AM, Stéphane Rollandin
<lecteur@zogotounga.net> wrote:Nice informative post, thanks Marcel.
I think I see something fragile in the implementation though: each
#userInterfaceTheme send must absolutely be followed by another selector,
else the relevant stacked object (in the scope inst. var. of the theme) will
not be popped at the proper moment.
In other words, a line of code as simple as
Morph new userInterfaceTheme explore
may break things in potentially ugly ways; for one thing, even if further
scope push/pop work properly, the Morph instanciated by the above code will
never be GCed...
Does that make sense?
StefFrom: Alan Pinch <alan.c.pinch@gmail.com>Subject: [squeak-dev] IPv6 implementation codeDate: 18. September 2017 um 03:46:49 MESZTo: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Could anyone be able to point me to working IPv6 code for squeak, please? I would appreciate any link.
AlanFrom: Alan Pinch <alan.c.pinch@gmail.com>Subject: [squeak-dev] ASN1 encoding of UTF8Date: 18. September 2017 um 03:49:37 MESZTo: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
I am trying to map utf8 into an ASN1 encoding, where the UTF8 is specified to perhaps extend past one byte in value. I am also interested in retaining this UTF8 characters in squeak to interoperate well. What would be my best approach to this, mapping to/from these bytes on a stream?
AlanFrom: "David T. Lewis" <lewis@mail.msen.com>Subject: Re: [squeak-dev] IPv6 implementation codeDate: 18. September 2017 um 04:44:54 MESZTo: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
On Sun, Sep 17, 2017 at 09:46:49PM -0400, Alan Pinch wrote:Could anyone be able to point me to working IPv6 code for squeak,
please? I would appreciate any link.
Alan
In the preferences browser, catagory general, set the preference for
"Enable IPv6 and new network support" to true.
The default setting is false, largely because of some network name
resolver issues on the Windows platform.
I do not think that the IPv6 code is exercised much, because most
people probably leave their image in the default mode. So if you are
using this and find problems with it, please let us know what does
not work.
DaveFrom: Jakob Reschke <jakob.reschke@student.hpi.de>Subject: Re: [squeak-dev] ASN1 encoding of UTF8Date: 18. September 2017 um 07:46:24 MESZTo: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>I just did a quick search on the web and it seems like ASN.1 has a UTF8String type (with tag 12) that just contains the sequence of bytes of the UTF-8-encoded string. Can you use that? See also this question on stackoverflow: https://stackoverflow.com/q/28929809 In Squeak, you can convert between UTF-8-encoded byte strings and decoded (Squeak-encoded) character strings with the help of UTF8TextConverter. Have a look at its class-side methods. Also, there are conversion methods in String, IIRC. Try to filter its instance-side methods by "utf8".Does this answer your question or are you in search of something else?Kind regards,JakobAm 18.09.2017 03:49 schrieb "Alan Pinch" <alan.c.pinch@gmail.com>:I am trying to map utf8 into an ASN1 encoding, where the UTF8 is
specified to perhaps extend past one byte in value. I am also interested
in retaining this UTF8 characters in squeak to interoperate well. What
would be my best approach to this, mapping to/from these bytes on a stream?
Alan
From: Marcel Taeumel <marcel.taeumel@hpi.de>Subject: Re: [squeak-dev] How should one implement a custom window color for a custom window?Date: 18. September 2017 um 09:13:32 MESZTo: Milan Vavra via Squeak-dev <squeak-dev@lists.squeakfoundation.org>Hi Stef,such fragility should usually be discovered quickly by the progarmmer that tries something like this. So, this is not considered an issue for bigger projects. Since Squeak is an interactive environment, the feedback loop is very short in this regard.As for your GC concerns: Can you construct a more elaborate example? If your environment experiences a severe memory issue, you should just try to clean-up the system like in the release process:UserInterfaceTheme cleanUp: true.orSmalltalk cleanUp: true.Since the "cope" instVar is local to a specific instance of UserInterfaceTheme, programmers can easily fix any issues there. One could also add a test case for that to improve usability. :)Best,MarcelAm 17.09.2017 14:04:21 schrieb Stéphane Rollandin <lecteur@zogotounga.net>:
Nice informative post, thanks Marcel.
I think I see something fragile in the implementation though: each
#userInterfaceTheme send must absolutely be followed by another
selector, else the relevant stacked object (in the scope inst. var. of
the theme) will not be popped at the proper moment.
In other words, a line of code as simple as
Morph new userInterfaceTheme explore
may break things in potentially ugly ways; for one thing, even if
further scope push/pop work properly, the Morph instanciated by the
above code will never be GCed...
Does that make sense?
Stef
From: commits@source.squeak.orgSubject: [squeak-dev] The Trunk: Tests-mt.382.mczDate: 18. September 2017 um 09:24:20 MESZTo: squeak-dev@lists.squeakfoundation.org, packages@lists.squeakfoundation.orgReply-To: squeak-dev@lists.squeakfoundation.org
Marcel Taeumel uploaded a new version of Tests to project The Trunk:
http://source.squeak.org/trunk/Tests-mt.382.mcz
==================== Summary ====================
Name: Tests-mt.382
Author: mt
Time: 18 September 2017, 9:24:02.443429 am
UUID: e9db6354-5602-3d4a-b944-ad65501bad8d
Ancestors: Tests-eem.381
Adds a test to verify the integrity of the environment's user interface themes wrt. scope.
=============== Diff against Tests-eem.381 ===============
Item was added:
+ ----- Method: UserInterfaceThemeTest>>test27ScopeIntegrity (in category 'tests') -----
+ test27ScopeIntegrity
+ "If application code manages to use Object >> #userInterfaceTheme without invoking the DNU dispatch directly afterwards, the theme's scope might get inconsistent. Even though this should usually never happen, check for it to be sure."
+
+ | issues |
+ issues := OrderedCollection new.
+ UserInterfaceTheme allThemes do: [:uit |
+ (uit instVarNamed: #scope) isEmpty ifFalse: [issues add: uit]].
+ self assert: issues isEmpty description: 'Some user interface themes have an inconsistent scope state, which can interfere with GC.'.!From: Alan Pinch <alan.c.pinch@gmail.com>Subject: Re: [squeak-dev] IPv6 implementation codeDate: 18. September 2017 um 10:19:54 MESZTo: squeak-dev@lists.squeakfoundation.org
I am running the Ubuntu 32-bit vm and I enabledIPv6: through the preferences browser. I am able to run yet it seems it is still IPv4. I do not know enough how IPv6 should work. I get the following host addresses:
Connection running..<cap://127.0.1.1:10012/Xrlgak8yDT0hgspNx0AyWoCdoZo=, cap://127.0.0.1:47684/FL4dilz6eq2sZDG5wKp3TFDoQEE=>
I get the following from NetNameResolver localAddressString
127.0.1.1
Alan
On 09/17/2017 10:44 PM, David T. Lewis wrote:On Sun, Sep 17, 2017 at 09:46:49PM -0400, Alan Pinch wrote:Could anyone be able to point me to working IPv6 code for squeak,In the preferences browser, catagory general, set the preference for
please? I would appreciate any link.
Alan
"Enable IPv6 and new network support" to true.
The default setting is false, largely because of some network name
resolver issues on the Windows platform.
I do not think that the IPv6 code is exercised much, because most
people probably leave their image in the default mode. So if you are
using this and find problems with it, please let us know what does
not work.
Dave
From: Alan Pinch <alan.c.pinch@gmail.com>Subject: Re: [squeak-dev] ASN1 encoding of UTF8Date: 18. September 2017 um 10:32:34 MESZTo: squeak-dev@lists.squeakfoundation.org
I had found the same stackover flow question. It is the only place I found that mentions that 0x0C is the tag for it.
I am currently encoding thus:
aString squeakToUtf8 asByteArray.
and decoding:
bytes asByteArray asString utf8ToSqueak.
Do you think this lays out the bytes as specified in this page? I gather from the stackoverflow that this would be the encoded form of utf8 for asn1.
https://en.wikipedia.org/wiki/UTF-8#Description
Alan
On 09/18/2017 01:46 AM, Jakob Reschke wrote:
I just did a quick search on the web and it seems like ASN.1 has a UTF8String type (with tag 12) that just contains the sequence of bytes of the UTF-8-encoded string. Can you use that? See also this question on stackoverflow: https://stackoverflow.com/q/28929809
In Squeak, you can convert between UTF-8-encoded byte strings and decoded (Squeak-encoded) character strings with the help of UTF8TextConverter. Have a look at its class-side methods. Also, there are conversion methods in String, IIRC. Try to filter its instance-side methods by "utf8".
Does this answer your question or are you in search of something else?
Kind regards,Jakob
Am 18.09.2017 03:49 schrieb "Alan Pinch" <alan.c.pinch@gmail.com>:
I am trying to map utf8 into an ASN1 encoding, where the UTF8 is
specified to perhaps extend past one byte in value. I am also interested
in retaining this UTF8 characters in squeak to interoperate well. What
would be my best approach to this, mapping to/from these bytes on a stream?
Alan
From: Stéphane Rollandin <lecteur@zogotounga.net>Subject: Re: [squeak-dev] How should one implement a custom window color for a custom window?Date: 18. September 2017 um 11:12:48 MESZTo: "liste [Squeak-dev]" <squeak-dev@lists.squeakfoundation.org>As for your GC concerns: Can you construct a more elaborate example? If your environment experiences a severe memory issue, you should just try to clean-up the system like in the release process:
I have no problem in my images, it's just by perusing the code that I saw that #userInterfaceTheme requires a specific handling.
What worries me is not the normal usage of #userInterfaceTheme, which works fine, it is how technically easy it is to mess things up, although I do not see that happening too often or at all actually. But if it happens sometime, somewhere, it will be a silent bug difficult to diagnose.
BTW I see that the #cleanUp: method will indeed reset all stacks in hard-coded subclasses of UserInterfaceTheme, but it will not do so for possibly existing other subclasses. So if I create my own MuOInterfaceTheme for example, I will also need to monkey-patch #cleanUp:.. Maybe we should iterate long #allSubclasses?
StefFrom: Marcel Taeumel <marcel.taeumel@hpi.de>Subject: Re: [squeak-dev] How should one implement a custom window color for a custom window?Date: 18. September 2017 um 11:17:35 MESZTo: Milan Vavra via Squeak-dev <squeak-dev@lists.squeakfoundation.org>Well, "Smalltalk cleanUp:except:" does exactly that, it iterates over all classes. :-) The call "UserInterfaceTheme cleanUp: true" was just an ad-hoc, oversimplified example for programmers to try out.I just added a new test for the themes. If the integrity of a theme is broken, one can just browse all senders of #userInterfaceTheme and debug. I claim that it is quite simple to diagnose. :)Best,MarcelAm 18.09.2017 11:12:52 schrieb Stéphane Rollandin <lecteur@zogotounga.net>:
> As for your GC concerns: Can you construct a more elaborate example? If
> your environment experiences a severe memory issue, you should just try
> to clean-up the system like in the release process:
I have no problem in my images, it's just by perusing the code that I
saw that #userInterfaceTheme requires a specific handling.
What worries me is not the normal usage of #userInterfaceTheme, which
works fine, it is how technically easy it is to mess things up, although
I do not see that happening too often or at all actually. But if it
happens sometime, somewhere, it will be a silent bug difficult to diagnose.
BTW I see that the #cleanUp: method will indeed reset all stacks in
hard-coded subclasses of UserInterfaceTheme, but it will not do so for
possibly existing other subclasses. So if I create my own
MuOInterfaceTheme for example, I will also need to monkey-patch
#cleanUp:.. Maybe we should iterate long #allSubclasses?
Stef
From: Stéphane Rollandin <lecteur@zogotounga.net>Subject: Re: [squeak-dev] How should one implement a custom window color for a custom window?Date: 18. September 2017 um 11:20:16 MESZTo: "liste [Squeak-dev]" <squeak-dev@lists.squeakfoundation.org>I don't see the example "never being GC'd" as being related to the
UserInterfaceTheme implementation. I may be missing your question but
Oh, easy to check: just do
100 timesRepeat: [Morph new userInterfaceTheme yourself].
then
UserInterfaceTheme current explore
... you will see all 100 instances of Morph in the stack.
StefFrom: Stéphane Rollandin <lecteur@zogotounga.net>Subject: Re: [squeak-dev] How should one implement a custom window color for a custom window?Date: 18. September 2017 um 11:23:15 MESZTo: "liste [Squeak-dev]" <squeak-dev@lists.squeakfoundation.org>UserInterfaceTheme cleanUp: true.
or
Smalltalk cleanUp: true.
Hmm I did:
100 timesRepeat: [Morph new userInterfaceTheme yourself].
UserInterfaceTheme cleanUp: true.
Smalltalk cleanUp: true.
UserInterfaceTheme current explore
... the scope stack was still populated.
StefFrom: Marcel Taeumel <marcel.taeumel@hpi.de>Subject: Re: [squeak-dev] How should one implement a custom window color for a custom window?Date: 18. September 2017 um 11:29:12 MESZTo: Milan Vavra via Squeak-dev <squeak-dev@lists.squeakfoundation.org>Thank you for this bug report. :)The current clean-up strategy is to dismiss existing instances of UserInterfaceTheme. In your example, the current theme was not touched and is still active. That is, your environment as an active theme that is not in the list "UserInterfaceTheme allThemes". The release building process usually picks a new theme after the clean-up, which your example did not.Anyway, I will fix the test to also consider the currently active theme. ;-)Best,MarcelAm 18.09.2017 11:23:18 schrieb Stéphane Rollandin <lecteur@zogotounga.net>:
> UserInterfaceTheme cleanUp: true.
>
> or
>
> Smalltalk cleanUp: true.
Hmm I did:
100 timesRepeat: [Morph new userInterfaceTheme yourself].
UserInterfaceTheme cleanUp: true.
Smalltalk cleanUp: true.
UserInterfaceTheme current explore
... the scope stack was still populated.
Stef
From: Stéphane Rollandin <lecteur@zogotounga.net>Subject: Re: [squeak-dev] How should one implement a custom window color for a custom window?Date: 18. September 2017 um 11:33:12 MESZTo: "liste [Squeak-dev]" <squeak-dev@lists.squeakfoundation.org>I just added a new test for the themes. If the integrity of a theme is broken, one can just browse all senders of #userInterfaceTheme and debug. I claim that it is quite simple to diagnose. :)
I am not too concerned by having the integrity of a theme broken. What I see more likely is objects accumulating silently in the stack until this becomes a problem.
StefFrom: commits@source.squeak.orgSubject: [squeak-dev] The Trunk: Tests-mt.382.mczDate: 18. September 2017 um 11:43:52 MESZTo: squeak-dev@lists.squeakfoundation.org, packages@lists.squeakfoundation.orgReply-To: squeak-dev@lists.squeakfoundation.org
Marcel Taeumel uploaded a new version of Tests to project The Trunk:
http://source.squeak.org/trunk/Tests-mt.382.mcz
==================== Summary ====================
Name: Tests-mt.382
Author: mt
Time: 18 September 2017, 9:24:02.443429 am
UUID: e9db6354-5602-3d4a-b944-ad65501bad8d
Ancestors: Tests-eem.381
Adds a test to verify the integrity of the environment's user interface themes wrt. scope.
=============== Diff against Tests-eem.381 ===============
Item was added:
+ ----- Method: UserInterfaceThemeTest>>test27ScopeIntegrity (in category 'tests') -----
+ test27ScopeIntegrity
+ "If application code manages to use Object >> #userInterfaceTheme without invoking the DNU dispatch directly afterwards, the theme's scope might get inconsistent. Even though this should usually never happen, check for it to be sure."
+
+ | issues |
+ issues := OrderedCollection new.
+ UserInterfaceTheme allThemes do: [:uit |
+ (uit instVarNamed: #scope) isEmpty ifFalse: [issues add: uit]].
+ self assert: issues isEmpty description: 'Some user interface themes have an inconsistent scope state, which can interfere with GC.'.!From: commits@source.squeak.orgSubject: [squeak-dev] The Trunk: Tests-mt.383.mczDate: 18. September 2017 um 11:44:02 MESZTo: squeak-dev@lists.squeakfoundation.org, packages@lists.squeakfoundation.orgReply-To: squeak-dev@lists.squeakfoundation.org
Marcel Taeumel uploaded a new version of Tests to project The Trunk:
http://source.squeak.org/trunk/Tests-mt.383.mcz
==================== Summary ====================
Name: Tests-mt.383
Author: mt
Time: 18 September 2017, 11:43:21.93578 am
UUID: a6f43f48-58a8-774e-8ad4-3b102f1fda9d
Ancestors: Tests-mt.382
Adds and fixes tests considering that current UI themes do not have to be registered such as in test code.
=============== Diff against Tests-mt.382 ===============
Item was changed:
----- Method: UserInterfaceThemeTest>>test27ScopeIntegrity (in category 'tests') -----
test27ScopeIntegrity
"If application code manages to use Object >> #userInterfaceTheme without invoking the DNU dispatch directly afterwards, the theme's scope might get inconsistent. Even though this should usually never happen, check for it to be sure."
| issues |
issues := OrderedCollection new.
UserInterfaceTheme allThemes do: [:uit |
(uit instVarNamed: #scope) isEmpty ifFalse: [issues add: uit]].
+ UserInterfaceTheme current in: [:uit |
+ (UserInterfaceTheme allThemes includes: uit)
+ ifFalse: [(uit instVarNamed: #scope) isEmpty ifFalse: [issues add: uit]]].
self assert: issues isEmpty description: 'Some user interface themes have an inconsistent scope state, which can interfere with GC.'.!
Item was added:
+ ----- Method: UserInterfaceThemeTest>>test28DanglingTheme (in category 'tests') -----
+ test28DanglingTheme
+
+ self
+ assert: (UserInterfaceTheme allThemes includes: UserInterfaceTheme current)
+ description: 'The current user interface theme is not registered.'.!
_______________________________________________
Squeak-dev mailing list
Squeak-dev@lists.squeakfoundation.org
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-dev