December 2015 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] e3f6b3: 50492
by GitHub Dec. 9, 2015

Dec. 9, 2015

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: e3f6b3f61fc8f36d306bbd3d8e0f125a369528ba https://github.com/pharo-project/pharo-core/commit/e3f6b3f61fc8f36d306bbd3d… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-12-09 (Wed, 09 Dec 2015) Changed paths: R Morphic-Core.package/Morph.class/instance/stepping and presenter/startSteppingIn_.st R Morphic-Core.package/PasteUpMorph.class/instance/world state/addMorphs_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50491.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50492.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50491.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50492.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50492 17221 clean dirty packages after metacello update https://pharo.fogbugz.com/f/cases/17221 17219 Class Definitions not in Changes... again again https://pharo.fogbugz.com/f/cases/17219 17217 Remove PasteUpMorph>>#addMorphs: https://pharo.fogbugz.com/f/cases/17217 http://files.pharo.org/image/50/50492.zip

1 0

where is the AST?
by Ben Coman Dec. 9, 2015

Dec. 9, 2015

I am probably misremembering, but I thought I used to be able to do something like... #+ implementors first inspect and spotter would show a CompiledMethod with a tab showing the Bytecode and AST, but I get a RGMethodDefinition that doesn't have those. How do I get those tabs up? This is just for a two minute example for demonstration purposes. cheers -ben

2 1

Help needed: old issues issue tracker entries
by marcus.denker＠inria.fr Dec. 9, 2015

Dec. 9, 2015

Hi, The issue tracker has 658 open issues. This number is more or less constant. We are fixing and integrating *a lot*, alone the last 7 days we managed to close 89 issue tracker entries. But the older entries see not much work. Of course one reason is that everything fixable gets fixed and only hard cases remainâ¦ but cases can be âdifficultâ for many reasons. I would be nice if everyone could help and have a look at older issues: -> Still relevant? -> Maybe already fixed? -> Is the description good? -> What is the next action that needs to be done? And keep in mind that the issue tracker is not a TODO list. If you see something odd and put and issue âoh, this looks oddâ but there is no action for a year, does it really make sense to keep that issue open? Every open issue takes energy away from the others. So please check if issues make sense of this kind: -> âIt would be nice ifâ but not even important enough for the submitter to do -> TODO issues that are huge projects in themselves -> â¦. It would be nice if *you* would check the issue that you have been involved with the last months and see what is needed to solve them. Marcus

9 11

displayingProgress on demand
by HernÃ¡n Morales Durand Dec. 9, 2015

Dec. 9, 2015

Hello everyone, Is there a reason why #collect:displayingProgress: was removed or never included? And as more general question, is there any pointer to automatically add progress bar to iterator messages? For example doing: SmalltalkImage setDisplayProgressTo: MyClass. SmalltalkImage setDisplayProgressTo: MyPackage. and then having all enumeration messages sent in MyClass or MyPackage with a progress bar collect: collect:as: collect:into: collect:thenDo: select: select:as: select:thenDo: select:thenCollect:as: ... HernÃ¡n

9 24

License agreement - are you kidding me?
by webwarrior Dec. 9, 2015

Dec. 9, 2015

It would be logical to make contribution to an open source project easy, right? Well, in bigger projects some burocracy is inevitable, but usually has some valid reasons behind it. When I made some commits to Spec (while it was on github), it was as easy as fork->commit->create pull request. In Pharo, it's already more complicated: you have to register yourself in SmalltalkHub, in fogbugz, in mailing lists. Slices system is also not very intuitive. Then CI system spits out some completely unrelated errors. But OK, I understand that Pharo is unlike, and the team maybe doesn't have time to migrate to some integrated bugtracker/repository/whatever. Then people began asking me of my real name - which is already wierd - why would they need it? And then someone suggested that I must sign license agreement (which is also wierd - MIT license doesn't demand anything like that). I looked at that agreeement. It requires you to provide name, address (???), sgin it and send it via snail mail (WTF???). No, guys, that is beyond good and evil. Either we skip this stupid formality and continue working on the code, or I'm out of this. -- View this message in context: http://forum.world.st/License-agreement-are-you-kidding-me-tp4865853.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

15 19

Re: [Pharo-dev] [Cuis] Sorting Unicode strings (Re: [Unicode] collation sequences (Re: [squeak-dev] Unicode Support))
by EuanM Dec. 9, 2015

Dec. 9, 2015

"The ffi_ligature (U+FB03) is not decomposed, because it has a compatibility mapping, not a canonical mapping." Standard's text from Table 7 "what the standard seems to say is, that the ffi ligature is not equivalent to plain ffi because, if i write a string with the ligature, then it is a different string than plain "ffi", because both forms are printable. on the other hand Ã¤ and a" (two different encodings for Ã¤) are the same, because the printed forms are always identical." --Martin I agree with that interpretation. I'm struggling to be clear about the consequences for equality testing. For sorting - every sort order can be created to go along with every encoding, so I suppose it just depends on which pre-assembled sort order is used. On 9 December 2015 at 02:36, Martin BÃ¤hr <mbaehr(a)email.archlab.tuwien.ac.at> wrote: > Excerpts from Martin BÃ¤hr's message of 2015-12-09 02:43:35 +0100: >> Excerpts from EuanM's message of 2015-12-09 01:59:43 +0100: >> > http://www.unicode.org/reports/tr15/#Stable_Code_Points >> > Table 7, the discussion of Ligatures, (which uses the ligature of >> > "ffi" as its example) >> >> Ã is not a ligature of ss, but is a different character. > > rereading this, i think i am wrong, in that this has nothing to do with Ã vs ss. > > looking at the standard i also don't understand your conclusion. > > what the standard seems to say is, that the ffi ligature is not equivalent to > plain ffi because, if i write a string with the ligature, then it is a > different string than plain "ffi", because both forms are printable. > on the other hand Ã¤ and a" (two different encodings for Ã¤) are the same, > because the printed forms are always identical. > > however that doesn't mean that they are sorted differently. > german sorting rules for example explicitly state that Ã and ss are sorted the same. > (at least according to wikipedia :-) > and surely, ffi ligature and ffi are sorted the same too. > > greetings, martin. > > -- > eKita - the online platform for your entire academic life > -- > chief engineer eKita.co > pike programmer pike.lysator.liu.se caudium.net societyserver.org > secretary beijinglug.org > mentor fossasia.org > foresight developer foresightlinux.org realss.com > unix sysadmin > Martin BÃ¤hr working in china http://societyserver.org/mbaehr/

1 0

Re: [Pharo-dev] [squeak-dev] Re: [Unicode] Class Unicode --> data from unicode.org
by EuanM Dec. 9, 2015

Dec. 9, 2015

Yes, clean room approaches are overkill. Obviousness in code has long been found to be a protection against copyright. For instance, you cannot copyright a programme in BASIC that says 10 Print "Hello World" 20 GOTO 10 (And by copyright, I mean prevent anyone else in the world from typing that programme and distributing their copy). One of the great advantage of writing weird, convoluted or just plain dense clever code is that it becomes non-obvious and therefore indubitably covered under copyright. The mere fact that code has been written somewhere, does *not* make it unusable elsewhere. (As an aside, I tend to write plain, straightforward code. Asserting copyright on a lot of it would be hard). One of the great advantages of not doing my coding in the USA is that Stallman would have to come after me in my jurisdiction, not his. Probably a special case of security through obscurity. Usual disclaimer. IANAL. Just interested in these issues from having developed legal support systems (including litigation support systems). As Hannes says, we haven't hit an area of the project where it is an issue yet. But personally, I'm quite relaxed about looking at the Gnu Smalltalk codebase. I'm pretty certain I can re-implement without violating copyright. In the same way I can prÃ©cis and paraphrase a short story without violating the copyright of the short story. Can any of you tell me the story of Hansel and Gretel without violating the copyright of some recently published re-telling of the tale? I'm pretty certain you could. Please remember that it is much easier to avoid copyright violation than it is to avoid patent violation, in these sorts of cases. None of the Gnu Smalltalk base is patented. Cheers, Euan (back to reading the ICU) On 7 December 2015 at 16:06, Martin BÃ¤hr <mbaehr(a)email.archlab.tuwien.ac.at> wrote: > Excerpts from Martin BÃ¤hr's message of 2015-12-07 16:17:28 +0100: >> randal schwartz suggests a cleanroom approach, though i personally think that >> is overkill. if a cleanroom approach were really necessary than i would never >> be allowed to switch jobs because once i have been working on one companys >> private code i would be tainted for life, as i could accidentally reproduce the >> same code in my next job. >> >> however, either you get the GNU-smalltalk authors to relicense their unicode >> classes under the MIT license, or they will need to be rewritten from scratch. >> >> i would suggest asking them in the name of having a common code-base for all >> smalltalks. > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-January/123817.… > is worth reading in that context: > > So it's mainly an issue of being willing to cooperate. I think all GNU > Smalltalk people (almost all?) are and it's also true at least for some > Squeak people. If somebody took a package (several thousands lines of > code, etc.) wholesale, ported it to Squeak, and licensed it under MIT on > SqueakMap that would be copyright violation. But everything can be done > "cum grano salis". Nobody is going to sue you if you copy an interface > from GNU Smalltalk, reimplement in Squeak (for fun!), but you did look > at the method comments in GNU Smalltalk -- and OMG maybe you got a > glimpse of the source code just below! Copyright does not protect > having similar implementations. > > I think we're all for interoperability and for exchange of opinions > within the communities. > > so there you have the open invitation to go and ask... > > and read this > http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-January/123838.… > for a good summary on the issue. > > greetings, martin. > > -- > eKita - the online platform for your entire academic life > -- > chief engineer eKita.co > pike programmer pike.lysator.liu.se caudium.net societyserver.org > secretary beijinglug.org > mentor fossasia.org > foresight developer foresightlinux.org realss.com > unix sysadmin > Martin BÃ¤hr working in china http://societyserver.org/mbaehr/

1 0

SecureSession version 9 is officially released
by Robert Withers Dec. 9, 2015

Dec. 9, 2015

Good evening, After some sprints over the past couple of days, the SecureSession project has reached an Official Release. This project implements a Certificateless secure connection, with no third parties. It is a 6 leg handshake. Here is the wiki: https://github.com/SqueakCryptographySquad/Mushroom/wiki/SecureSession thank You, Robert

1 0

Documentation epiphany
by Ben Coman Dec. 8, 2015

Dec. 8, 2015

I just understood! Other languages might get better documentation because of all the extra slack time they get between compile cycles, that we don't get with Pharo's tight code-run-debug loop. I know... not a valid excuse for us**, but then I get to show this... https://xkcd.com/303/ ** of course documentation is getting better every day - but I can't let the truth get in the way of a good story :) cheers -ben

4 4

Re: [Pharo-dev] [Unicode] Normalization -- canonical equivalence vs compatibility equivalence
by EuanM Dec. 8, 2015

Dec. 8, 2015

canonical equivalence ================ aString = anotherStrong where both strings are of the same sequence of valid Unicode representations of abstract characters BUT each individual character MAY (or may not) be represented by different valid Unicode representations of the character e.g. #(00c5) = #(212b) = #(0041 030a) "The same meaning when printed or displayed" Every tuple of canonically equivalent sequences is also compatibility equivalent. Actually yes - the easy way to define it would be a canonically equivalent string is the same string sequence of the same abstract characters as the string you are comparing it to. (But may use different codepoints) The sequence will have the same glyph appearance. compatibility equivalence is ===================== aString = anotherStrong where both strings have the same meaning in some particular contexts, but may have a different glyph appearance e.g. comparing ligatures with the decomposed sequences making up a ligature as in "ss" = "Ã" This is compatibility equivalent, they *can* have the same meaning, but they never have the same appearance. The normalisation forms either - expand all compatibility codepoints into fully composed sequences, to create the "fully composed normal form" of the string OR fully condense all composed sequences into compatibility codepoints, to create a "fully decomposed normal form". (Note, that as there can be multiple compatibility codepoints for an abstract character, it is necessary to create fully decomposed forms only after first coverting to fully composed forms, or two fully decomposed strings could fail equivalance testing *despite* being compatibility equivalent. e.g. #(00c5 00c5 00c5) = #(212b 212b 212b) is actually true, for compatibility equivalence But a process of fully composing any of #(00c5 212b #(0041 030a) ) #(00c5 00c5 00c5) #(212b 212b 212b) would always produce #( #(0041 030a) #(0041 030a) #(0041 030a) ) and then a subsequent full decomposition would produce #(00c5 00c5 00c5) for all three cases. On 8 December 2015 at 16:09, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > It seems that going for Normalization first in order to implement > String comparison is the next necessary steps. This is already a > result by itself. > > Normalization (Unicode) > Last updated at 4:05 pm UTC on 8 December 2015 > http://wiki.squeak.org/squeak/6229 > > Can you explain to me what the difference between > > canonical equivalence > and > compatibility equivalence > > and for which we should go? > > --Hannes

1 0