[Box-Admins] INFO: blocked by Microsoft
Tobias Pape
Das.Linux at gmx.de
Wed Sep 20 10:43:49 UTC 2017
Dear all
our mailserver is being blocked by mircosoft (live/outlook.com etc.) for
sending from a rackspace IP range that is allegedly known for spamming.
I asked for removal but that didn't work, apparently.
I have no intention to fix that, too much effort, to be frank.
best regards
-Tobias
> Begin forwarded message:
>
> From: mailman at lists.squeakfoundation.org
> Subject: Bounce action notification
> Date: 20. September 2017 um 12:23:16 MESZ
> To: squeak-dev-owner at lists.squeakfoundation.org
> Delivered-To: squeak-dev-owner at mail.squeak.org
>
> This is a Mailman mailing list bounce action notice:
>
> List: Squeak-dev
> Member: otadini at 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 at lists.squeakfoundation.org.
>
> From: MAILER-DAEMON at mail.squeak.org (Mail Delivery System)
> Subject: Undelivered Mail Returned to Sender
> Date: 20. September 2017 um 12:16:47 MESZ
> To: squeak-dev-bounces at lists.squeakfoundation.org
> Delivered-To: squeak-dev-bounces at 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 at 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 at squeak.org
> Arrival-Date: Mon, 18 Sep 2017 12:00:02 +0000 (UTC)
>
> Final-Recipient: rfc822; otadini at outlook.com
> Original-Recipient: rfc822;otadini at 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.
>
> From: squeak-dev-request at lists.squeakfoundation.org
> Subject: Squeak-dev Digest, Vol 177, Issue 17
> Date: 18. September 2017 um 14:00:01 MESZ
> To: squeak-dev at lists.squeakfoundation.org
> Reply-To: squeak-dev at lists.squeakfoundation.org
>
>
> Send Squeak-dev mailing list submissions to
> squeak-dev at 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 at lists.squeakfoundation.org
>
> You can reach the person managing the list at
> squeak-dev-owner at 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 at 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 at source.squeak.org)
> 18. The Trunk: Tests-mt.383.mcz (commits at source.squeak.org)
>
> From: Stéphane Rollandin <lecteur at 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 MESZ
> To: "liste [Squeak-dev]" <squeak-dev at 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?
>
>
> Stef
>
>
>
>
> From: Chris Muller <asqueaker at 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 MESZ
> To: The general-purpose Squeak developers list <squeak-dev at lists.squeakfoundation.org>
> Reply-To: ma.chris.m at 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 at 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?
>>
>>
>> Stef
>>
>
>
>
>
> From: Alan Pinch <alan.c.pinch at gmail.com>
> Subject: [squeak-dev] IPv6 implementation code
> Date: 18. September 2017 um 03:46:49 MESZ
> To: The general-purpose Squeak developers list <squeak-dev at lists.squeakfoundation.org>
>
>
> Could anyone be able to point me to working IPv6 code for squeak, please? I would appreciate any link.
>
> Alan
>
>
>
>
> From: Alan Pinch <alan.c.pinch at gmail.com>
> Subject: [squeak-dev] ASN1 encoding of UTF8
> Date: 18. September 2017 um 03:49:37 MESZ
> To: The general-purpose Squeak developers list <squeak-dev at 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?
>
> Alan
>
>
>
>
>
> From: "David T. Lewis" <lewis at mail.msen.com>
> Subject: Re: [squeak-dev] IPv6 implementation code
> Date: 18. September 2017 um 04:44:54 MESZ
> To: The general-purpose Squeak developers list <squeak-dev at 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.
>
> Dave
>
>
>
>
>
> From: Jakob Reschke <jakob.reschke at student.hpi.de>
> Subject: Re: [squeak-dev] ASN1 encoding of UTF8
> Date: 18. September 2017 um 07:46:24 MESZ
> To: The general-purpose Squeak developers list <squeak-dev at 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 <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 at gmail.com <mailto:alan.c.pinch at 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 at 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 MESZ
> To: Milan Vavra via Squeak-dev <squeak-dev at 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.
>
> or
>
> Smalltalk 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,
> Marcel
>> Am 17.09.2017 14:04:21 schrieb Stéphane Rollandin <lecteur at 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 at source.squeak.org
> Subject: [squeak-dev] The Trunk: Tests-mt.382.mcz
> Date: 18. September 2017 um 09:24:20 MESZ
> To: squeak-dev at lists.squeakfoundation.org, packages at lists.squeakfoundation.org
> Reply-To: squeak-dev at 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 at gmail.com>
> Subject: Re: [squeak-dev] IPv6 implementation code
> Date: 18. September 2017 um 10:19:54 MESZ
> To: squeak-dev at 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,
>>> 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.
>>
>> Dave
>>
>
>
>
>
>
> From: Alan Pinch <alan.c.pinch at gmail.com>
> Subject: Re: [squeak-dev] ASN1 encoding of UTF8
> Date: 18. September 2017 um 10:32:34 MESZ
> To: squeak-dev at 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 <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 <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 at gmail.com <mailto:alan.c.pinch at 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 at 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 MESZ
> To: "liste [Squeak-dev]" <squeak-dev at 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?
>
> Stef
>
>
>
>
> From: Marcel Taeumel <marcel.taeumel at 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 MESZ
> To: Milan Vavra via Squeak-dev <squeak-dev at 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,
> Marcel
>> Am 18.09.2017 11:12:52 schrieb Stéphane Rollandin <lecteur at 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 at 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 MESZ
> To: "liste [Squeak-dev]" <squeak-dev at 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.
>
>
> Stef
>
>
>
>
> From: Stéphane Rollandin <lecteur at 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 MESZ
> To: "liste [Squeak-dev]" <squeak-dev at 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.
>
>
> Stef
>
>
>
>
> From: Marcel Taeumel <marcel.taeumel at 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 MESZ
> To: Milan Vavra via Squeak-dev <squeak-dev at 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,
> Marcel
>> Am 18.09.2017 11:23:18 schrieb Stéphane Rollandin <lecteur at 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 at 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 MESZ
> To: "liste [Squeak-dev]" <squeak-dev at 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.
>
> Stef
>
>
>
>
> From: commits at source.squeak.org
> Subject: [squeak-dev] The Trunk: Tests-mt.382.mcz
> Date: 18. September 2017 um 11:43:52 MESZ
> To: squeak-dev at lists.squeakfoundation.org, packages at lists.squeakfoundation.org
> Reply-To: squeak-dev at 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 at source.squeak.org
> Subject: [squeak-dev] The Trunk: Tests-mt.383.mcz
> Date: 18. September 2017 um 11:44:02 MESZ
> To: squeak-dev at lists.squeakfoundation.org, packages at lists.squeakfoundation.org
> Reply-To: squeak-dev at 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 at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/box-admins/attachments/20170920/5a9a1fe5/attachment-0001.html>
More information about the Box-Admins
mailing list