Re: [Pharo-dev] Unicode Support
"Well. I do not agree with this. I agree with the quote. Can you explain a bit more about what you mean by abstract character and concept?" Guillermo The problem with the quote is, that *while true*, it *does not disambiguate* between: either compatibility character and abstract character; or character as composable component of an abstract character and character as the entire embodiment of an abstract character; Abstract character is the key concept of Unicode. Differentiation between abstract character and codepoints is the key differentiator of the Unicode approach and most previous approaches to character encoding, e,g, ASCII, EBCDIC, ISO Latin 1, etc Please see my previous posts which use the example of Angstrom, Capital A with circle (or whatever the canonical name is) and the composed sequence of "Capital A" and "circle above a letter" for a fuller explanation of the concept of "abstract character". On 9 December 2015 at 09:35, Guillermo Polito wrote: > >> On 8 dic 2015, at 10:07 p.m., EuanM wrote: >> >> "No. a codepoint is the numerical value assigned to a character. An >> "encoded character" is the way a codepoint is represented in bytes >> using a given encoding." >> >> No. >> >> A codepoint may represent a component part of an abstract character, >> or may represent an abstract character, or it may do both (but not >> always at the same time). >> >> Codepoints represent a single encoding of a single concept. >> >> Sometimes that concept represents a whole abstract character. >> Sometimes it represent part of an abstract character. > > Well. I do not agree with this. I agree with the quote. > > Can you explain a bit more about what you mean by abstract character and > concept? > >> >> This is the key difference between Unicode and most character encodings. >> >> A codepoint does not always represent a whole character. >> >> On 7 December 2015 at 13:06, Henrik Johansen >> wrote: >>> >>> On 07 Dec 2015, at 1:05 , EuanM wrote: >>> >>> Hi Henry, >>> >>> To be honest, at some point I'm going to long for the for the much >>> more succinct semantics of healthcare systems and sports scoring and >>> administration systems again. :-) >>> >>> codepoints are any of *either* >>> - the representation of a component of an abstract character, *or* >>> eg. "A" #(0041) as a component of >>> - the sole representation of the whole of an abstract character *or* of >>> - a representation of an abstract character provided for backwards >>> compatibility which is more properly represented by a series of >>> codepoints representing a composed character >>> >>> e.g. >>> >>> The "A" #(0041) as a codepoint can be: >>> the sole representation of the whole of an abstract character "A" #(0041) >>> >>> The representation of a component of the composed (i.e. preferred) >>> version of the abstract character Å #(0041 030a) >>> >>> Å (#00C5) represents one valid compatibility form of the abstract >>> character Å which is most properly represented by #(0041 030a). >>> >>> Å (#212b) also represents one valid compatibility form of the abstract >>> character Å which is most properly represented by #(0041 030a). >>> >>> With any luck, this satisfies both our semantic understandings of the >>> concept of "codepoint" >>> >>> Would you agree with that? >>> >>> In Unicode, codepoints are *NOT* an abstract numerical representation >>> of a text character. >>> >>> At least not as we generally understand the term "text character" from >>> our experience of non-Unicode character mappings. >>> >>> >>> I agree, they are numerical representations of what Unicode refers to as >>> characters. >>> >>> >>> codepoints represent "*encoded characters*" >>> >>> >>> No. a codepoint is the numerical value assigned to a character. An "encoded >>> character" is the way a codepoint is represented in bytes using a given >>> encoding. >>> >>> and "a *text element* ... >>> is represented by a sequence of one or more codepoints". (And the >>> term "text element" is deliberately left undefined in the Unicode >>> standard) >>> >>> Individual codepoints are very often *not* the encoded form of an >>>
Re: [Pharo-dev] Help needed: old issues issue tracker entries
Excellent. Can I suggest that in future they are simply closed, rather than re-assigned? On 3 December 2015 at 06:35, Nicolai Hess wrote: > > Am 03.12.2015 1:08 vorm. schrieb "EuanM" : >> >> I had an issue assigned against me, which I have not the time nor the >> knowledge to fix. >> >> (Inconstant aspect ratio of Desktop background image). >> >> Can I suggest it is given to someone who knows the Desktop GUI codebase? >> >> (If I was in a position to fix it, I would have just submitted a fix, >> not a bug report) > > It was assigned to "everyone". And just assigned to you after a fix was > provided. > That issue is already closed. > >> >> On 2 December 2015 at 13:42, webwarrior wrote: >> > Case 16725 - Merge changes from spec github repository. >> > 2 subcases are resolved, 2 other need decision. Nothing time-consuming - >> > just decide if we integrate them or mark as wontfix. >> > >> > >> > Case 15927 - Menu is broken when contained in a list. >> > This is much more complicated, it's even not clear which class >> > (TransfromMorph or MenuItemMorph) is bugged. >> > I tried to fix it myself, but had no success. >> > >> > >> > >> > -- >> > View this message in context: >> > http://forum.world.st/Help-needed-old-issues-issue-tracker-entries-tp4864269p4864751.html >> > Sent from the Pharo Smalltalk Developers mailing list archive at >> > Nabble.com. >> > >>
Re: [Pharo-dev] Unicode Support
"No. a codepoint is the numerical value assigned to a character. An "encoded character" is the way a codepoint is represented in bytes using a given encoding." No. A codepoint may represent a component part of an abstract character, or may represent an abstract character, or it may do both (but not always at the same time). Codepoints represent a single encoding of a single concept. Sometimes that concept represents a whole abstract character. Sometimes it represent part of an abstract character. This is the key difference between Unicode and most character encodings. A codepoint does not always represent a whole character. On 7 December 2015 at 13:06, Henrik Johansen wrote: > > On 07 Dec 2015, at 1:05 , EuanM wrote: > > Hi Henry, > > To be honest, at some point I'm going to long for the for the much > more succinct semantics of healthcare systems and sports scoring and > administration systems again. :-) > > codepoints are any of *either* > - the representation of a component of an abstract character, *or* > eg. "A" #(0041) as a component of > - the sole representation of the whole of an abstract character *or* of > - a representation of an abstract character provided for backwards > compatibility which is more properly represented by a series of > codepoints representing a composed character > > e.g. > > The "A" #(0041) as a codepoint can be: > the sole representation of the whole of an abstract character "A" #(0041) > > The representation of a component of the composed (i.e. preferred) > version of the abstract character Å #(0041 030a) > > Å (#00C5) represents one valid compatibility form of the abstract > character Å which is most properly represented by #(0041 030a). > > Å (#212b) also represents one valid compatibility form of the abstract > character Å which is most properly represented by #(0041 030a). > > With any luck, this satisfies both our semantic understandings of the > concept of "codepoint" > > Would you agree with that? > > In Unicode, codepoints are *NOT* an abstract numerical representation > of a text character. > > At least not as we generally understand the term "text character" from > our experience of non-Unicode character mappings. > > > I agree, they are numerical representations of what Unicode refers to as > characters. > > > codepoints represent "*encoded characters*" > > > No. a codepoint is the numerical value assigned to a character. An "encoded > character" is the way a codepoint is represented in bytes using a given > encoding. > > and "a *text element* ... > is represented by a sequence of one or more codepoints". (And the > term "text element" is deliberately left undefined in the Unicode > standard) > > Individual codepoints are very often *not* the encoded form of an > abstract character that we are interested in. Unless we are > communicating to or from another system (Which in some cases is the > Smalltalk ByteString class) > > > > > i.e. in other words > > *Some* individual codepoints *may* be a representation of a specific > *abstract character*, but only in special cases. > > The general case in Unicode is that Unicode defines (a) > representation(s) of a Unicode *abstract character*. > > The Unicode standard representation of an abstract character is a > composed sequence of codepoints, where in some cases that sequence is > as short as 1 codepoint. > > In other cases, Unicode has a compatibility alias of a single > codepoint which is *also* a representation of an abstract character > > There are some cases where an abstract character can be represented by > more than one single-codepoint compatibility codepoint. > > Cheers, > Euan > > > I agree you have a good grasp of the distinction between an abstract > character (characters and character sequences which should be treated > equivalent wrt, equality / sorting / display, etc.) and a character (which > each have a code point assigned). > That is besides the point both Sven and I tried to get through, which is the > difference between a code point and the encoded form(s) of said code point. > When you write: > "and therefore encodable in UTF-8 as compatibility codepoint e9 hex > and as the composed character #(0065 00b4) (all in hex) and as the > same composed character as both > #(feff 0065 00b4) and #(ffef 0065 00b4) when endianness markers are > included" > > I's quite clear you confuse the two. 0xFEFF is the codepoint of the > character used as bom. > When you state that it can be written ffef (I assume you meant FFFE), you > are again confusing the code point and its encoded value (an encoded value > which only occurs in UTF16/32, no less). > > When this distinction is clear, it might be easier to see that value in that > Strings are kept as Unicode code points arrays, and converted to encoded > forms when entering/exiting the system. > > Cheers, > Henry >
Re: [Pharo-dev] License agreement - are you kidding me?
"What you lose is the right to take out your code (and to change the licensing of it retroactively…)." That is only true in one sense. 1) The author cannot demand that the code is removed from the codebase - as the original grant of licence was irrevocable. (Or at least, this is proven true in UK and US jurisdictions - I have no knowledge of the case mutability of French law). The author *can* request that, and the publishers can accede to that request, if they choose. 2) The author cannot demand to have the terms of licence changed for code which has been accepted into the codebase. The author *can* request that, and the publishers can accede to that request, if they choose. 3) The author wrote the code, and provided a copy of it to the publisher. Unless s/he explicitly provided sole use to the publisher, he can provide that same code to any other group or publisher as s/he sees fit, under any license terms (or none) s/he chooses. Providing a copy of the code under a different licence is functionally equivalent to some interpretations of the quoted sentence. On 8 December 2015 at 10:42, Esteban Lorenzano wrote: > so, first of all, I find the way you communicate your arguments a bit… well, > not very polite. > second, even Ben’s affaire should show you why we value this license > agreements. > third, French laws are French laws and since the development of Pharo is in > a big extent made here (through INRIA), French laws needs to be fulfilled. > And no, there are no exceptions… we wouldn’t be able to operate here without > that: French law does not recognise digital signatures, checkbox or anything > that comes from the “virtual world” (we have a lot of funny examples of > things we decide to to request from other EU countries because if we request > it here, we need to send them a contract by mail). > four, no copyright is lost. Your code keeps your name, etc. What you lose is > the right to take out your code (and to change the licensing of it > retroactively…). > five, nobody forces you to do anything. I’m really sorry you take this as a > personal prosecution (or a personal battle)… while I value all contributions > and discussions (and I certainly would like you continue contributing), I > find the tone of your reclamation a little bit out-of-the-tone of a real > argumentation… kind of trollish… so I wonder if you really want to discuss > something or not… > > cheers! > Esteban > > On 08 Dec 2015, at 00:47, webwarrior wrote: > > Considering that there are a couple of responses and the fact that you > guys are so easily offended, I will not answer everyone but just state > couple of theses. > > > 0. I will not reveal my real name, because I value privacy. Nickname is > sufficient for identification purposes. Any other information (real > name, address, etc.) is not needed for actually contributing code. Think > of principle of least privilege. > > 1. I could easily make up some human-looking name (Satoshi Nakamoto > anyone?), but will not do it out of principle (see #0). > > 2. Knowing contributor's "real" name would not guard you against any > possible malicious actions from him, because it can't be verified (see > #1). One can also make up address, and even signature, if needed, and I > bet no one would spot it. > > 3. I don't buy argument about requirements of some organizations. Linux > kernel is used in billions of devices and by countless organizations, > and I highly doubt that contributing to Linux requires anything like > singing an agreement or whatever. > > 4. Even in paid services checking a checkbox is usually sufficient for > accepting any license/ToS. > > 5. My intentions are mostly of pragmatic nature. To make things that I > use (and that can be useful to Pharo users) be in upstream. > > 6. I don't care whether you drink beer, your political views, or your > interpersonal relationships (however story with Benjamin shows that > perhaps everything's not as great as you paint it). These are all > irrelevant to Pharo development, from my point of view at least. > > 7. If you don't agree with my arguments and stick to your rules, go for > it. I'm in no position to tell you what's the right thing to do. I'll > just end this discussion and leave. > > > View this message in context: Re: License agreement - are you kidding me? > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >
Re: [Pharo-dev] License agreement - are you kidding me?
"The Pharo community is quite small" Yes, and that is a major issue. Both for feature-completeness in a timely fashion, and also for commercial uptake of use of Pharo. Saying that it's small, so it's okay to make it difficult for people to join is... self-fulfilling. On 8 December 2015 at 07:35, Peter Uhnak wrote: > On 12/07, webwarrior wrote: >> 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 > > Not every project lives in GitHub. > For Ruby, Mozilla, Chromium, Python, PHP, ... you have to register to > their bug tracker. After all, these projects predate both GitHub AND > git. > >> Then people began asking me of my real name - which is already wierd - why >> would they need it? > > The Pharo community is quite small and many people know each other > personally (have met on Pharo Days, ESUG, are coworkers, ...). So > working with someone who goes well out of his way to remain anonymous may be > uncomfortable for some. Not to mention that such behavior may seem > strange for OSS, but that's your call. > >> >> And then someone suggested that I must sign license agreement (which is also >> wierd - MIT license doesn't demand anything like that). > > The MIT may not demand something like that, however signing License > Agreement is also not completely unheard of, see for example > https://en.wikipedia.org/wiki/Contributor_License_Agreement#Users > > This includes names like Python, Apache, jQuery, Django, ... not exactly > small fishes. > > >> I looked at that agreeement. It requires you to provide name, address (???), >> sgin it and send it via snail mail (WTF???). > > See above. Also note that copyright in many countries recognized > pseudonyms as valid authors. (I am not familiar with French law, but I will > assume it is harmonized across EU) > Of course in case of a dispute you would need to be able to prove that > you are the pseudonym (otherwise you yourself would loose the rights). > > So considering your position (revealing your real name would undermine > all the work you've put into protecting it), going with a pseudonym if > you are indeed willing to contribute may be the best course of action. > >> -- >> 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. >> > > -- > Peter >
Re: [Pharo-dev] License agreement - are you kidding me?
"partially anonymous" The correct word is "pseudonimity". In UK law, as long as there is no intent to defraud, you can call yourself anything you like. In UK, you can provide signatures digitally, completely legally. UK law is has a long tradition of sorting out legal issues between two-third party jurisdictions. Perhaops Pharo ought to do it's work under a legal system that is more completely designed to handle issues of international commerce? Or perhaps it should be a all-French affair. On 7 December 2015 at 20:26, Torsten Bergmann wrote: > Hi webwarrior (or whatever your name now is ;) > > There is always room for improvements - even for better guidance on how to > become > a contributor. There are good reasons to do things the way they are done now > - and > yes some of them are not optimal because of history or because of sparse time. > > Lamenting partially anonymous from the outside is neither useful nor polite. > Working as a real member/part of the community on the other side can help us > all to move > forward step by step with a better open source project. > > If you or any other is really interested in moving with us the registration or > signature for sure will not be the show stopper. > >>Either we skip this stupid formality and continue working on the code, or >>I'm out of this. > > As Stef explained this was not done to bug people or keep them away. > We know that it might be cumbersome at first sight - but hey, many people > mastered this > easily. I guess we even have people who do not drink beer but wine instead :) > > You can decide on your own how to proceed. Turn away or return. I guess there > is only > one big hurdle and this one is on your side ;) > > As you see friendly people continue to invest their time answering your mails > although you > as the author not even have the time (or will) to reveal your name. IMHO if > someone > wants to participate in an open source project he has to be "open" on its own > side first. > > It's up to you... > > Thanks > T. > > >
Re: [Pharo-dev] [Cuis] Sorting Unicode strings (Re: [Unicode] collation sequences (Re: [squeak-dev] Unicode Support))
Dale - is that you can't depend on the value of a codepoint *unless the string is either in fully-composed form (or has just been fully-decomposed from a fully-composed form) * OR are there circumstances where even those two cases cannot be relied upon? On 8 December 2015 at 19:20, Dale Henrichs wrote: > > > On 12/07/2015 11:31 PM, H. Hirzel wrote: >> >> Dale >> >> Thank you for your answer with links to the ICU library and the notes >> about classes in Gemstone. Noteworthy that you have a class Utf8 as a >> subclass of ByteArray. >> >> I understand that Gemstone uses the ICU library and thus does not >> implement the algorithms in Smalltalk. >> >> I am currently looking into what the ICU library provides. >> >> I found as well a Ruby library [2] which implements CLDR [3] >> >> It has methods like this >> >> "Alphabetize a list using regular Ruby sort:" >> >> $> ["Art", "Wasa", "Älg", "Ved"].sort >> $> ["Art", "Ved", "Wasa", "Älg"] >> >> Alphabetize a list using TwitterCLDR’s locale-aware sort: >> >> $> ["Art", "Wasa", "Älg", "Ved"].localize(:de).sort.to_a >> $> ["Älg", "Art", "Ved", "Wasa"] >> >> I hope that given such an example it would not be too difficult to >> reimplement a similar sort algorithm in Squeak/Cuis/Pharo. Currently >> the interest is in getting sorting done in a cross-dialect-way. >> > > I think that the issue (from a performance perspective) is that you can't > depend upon the value of the code point when doing collation --- the main > algorithm[5] is pretty much table based --- In addition to the different > sort orders based on characters there are even more arcane sort rules where > characters at the end of a word can affect the sort order of the word (for > more info see[4]). > > It is worth looking at the Conformance section of the Unicode spec[1] as > there are different levels of collation conformance . > > ICU conforms[2] to to UTS #10[3], the highest level of conformance ... > > It looks like TwitterCLDR[6] uses the Main Algorithm[5] with tailoring[7]. > They don't claim to be conformant to the Unicode Collation Algorithm[3], but > they are covering a big chunk of the standard use cases > > Dale > > [1] http://unicode.org/reports/tr10/#Conformance > [2] http://userguide.icu-project.org/collation > [3] http://www.unicode.org/reports/tr10/ > [4] http://www.unicode.org/reports/tr10/#Introduction > [5] http://www.unicode.org/reports/tr10/#Main_Algorithm > [6] > https://blog.twitter.com/2012/twittercldr-improving-internationalization-support-in-ruby > [7] http://unicode.org/reports/tr10/#Tailoring
Re: [Pharo-dev] Documentation epiphany
The joke it's based on pre-dates use of computers to render complex 3D :-) Here's the world's first computer-generated 3D movie, from the Uni of Utah in 1972: https://vimeo.com/16292363 Compiled languages predate this. On 8 December 2015 at 15:24, Dimitris Chloupis wrote: > Actually this joke I think is "stolen" by a previous joke about 3d artists , > because our rendering times can be way longer than compiling the most > complex C++ code. Easily can reach months of rendering time. > > Its a good joke, but it should be taken as it is , a joke and nothing more. > > Because I happen to build blender from time to time which is 1 million lines > of destruction code, aka C/C++ code. Compiling is not that bad. Sure C++ > still is hog slow and outperformed 10 times by Pascal compilers which I > think that even the Pharo compiler would have a hard time competing with. > But makefiles are smart enough to compile and re link whatever it changes > and not the whole project. > > So each new commit I fetch for Blender produces a couple of seconds of > compiling time. But the very first compile which compiles everything from > scratch can reach even an hour and is not even a complete compile since I > use many prebuilt libraries and some prebuilt dependencies. > > To the subject of documentation it comes attached with a big depends. > Documentation is the usual problem pretty much with any programming > languages and is based on the fact that coders dont like to document as much > they dont like to design good code and make very good GUIs. > > Frankly you should always feel glad if you find documentation in any > language your are coding. If its good documentation too, then its your lucky > day indeed. > > But even in popular languages like Python, sure plenty of documentation for > the standard stuff but the moment you start depend on third party libraries > you are all alone VS the Alien :D > > On Tue, Dec 8, 2015 at 4:42 PM Ben Coman wrote: >> >> 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 >> >
Re: [Pharo-dev] Unicode Support
And indeed, in principle. On 7 December 2015 at 10:51, EuanM wrote: > Verifying assumptions is the key reason why you should documents like > this out for review. > > Sven - > > Cuis is encoded with ISO 8859-15 (aka ISO Latin 9) > > Sven, this is *NOT* as you state, ISO 99591, (and not as I stated, 8859-1). > > We caught the right specification bug for the wrong reason. > > Juan: "Cuis: Chose not to use Squeak approach. Chose to make the base > image include and use only 1-byte strings. Chose to use ISO-8859-15" > > I have double-checked - each character encoded in ISO Latin 15 (ISO > 8859-15) is exactly the character represented by the corresponding > 1-byte codepoint in Unicode to 00FF, > > with the following exceptions: > > codepoint 20ac - Euro symbol > character code a4 (replaces codepoint 00a4 generic currency symbol) > > codepoint 0160 Latin Upper Case S with Caron > character code a6 (replaces codepoint 00A6 was | Unix pipe character) > > codepoint 0161 Latin Lower Case s with Caron > character code a8 (replaces codepoint 00A8 was dierisis) > > codepoint 017d Latin Upper Case Z with Caron > character code b4 (replaces codepoint 00b4 was Acute accent) > > codepoint 017e Latin Lower Case Z with Caron > character code b8 (replaces codepoint 00b8 was cedilla) > > codepoint 0152 Upper Case OE ligature = Ethel > character code bc (replaces codepoint 00bc was 1/4 symbol) > > codepoint 0153 Lower Case oe ligature = ethel > character code bd (replaces codepoint 00bd was 1/2 symbol) > > codepoint 0178 Upper Case Y diaeresis > character code be (replaces codepoint 00be was 3/4 symbol) > > Juan - I don't suppose we could persuade you to change to ISO Latin-1 > from ISO Latin-9 ? > > It means we could run the same 1 byte string encoding across Cuis, > Squeak, Pharo, and, as far as I can make out so far, Dolphin Smalltalk > and Gnu Smalltalk. > > The downside would be that French Y diaeresis would lose the ability > to use that character, along with users of oe, OE, and s, S, z, Z with > caron. Along with the Euro. > > https://en.wikipedia.org/wiki/ISO/IEC_8859-15. > > I'm confident I understand the use of UTF-8 in principal. > > > On 7 December 2015 at 08:27, Sven Van Caekenberghe wrote: >> I am sorry but one of your basic assumptions is completely wrong: >> >> 'Les élèves Français' encodeWith: #iso99591. >> >> => #[76 101 115 32 233 108 232 118 101 115 32 70 114 97 110 231 97 105 115] >> >> 'Les élèves Français' utf8Encoded. >> >> => #[76 101 115 32 195 169 108 195 168 118 101 115 32 70 114 97 110 195 167 >> 97 105 115] >> >> ISO-9959-1 (~Latin1) is NOT AT ALL identical to UTF-8 in its upper, non-ACII >> part !! >> >> Or shorter, $é is encoded in ISO-9959-1 as #[233], but as #[195 169] in >> UTF-8. >> >> So more than half the points you make, or the facts that you state, are thus >> plain wrong. >> >> The only thing that is correct is that the code points are equal, but that >> is not the same as the encoding ! >> >> From this I am inclined to conclude that you do not fundamentally understand >> how UTF-8 works, which does not strike me as good basis to design something >> called a UTF8String. >> >> Sorry. >> >> PS: Note also that Cuis' choice to use ISO-9959-1 only is pretty limiting in >> a Unicode world. >> >>> On 07 Dec 2015, at 04:21, EuanM wrote: >>> >>> This a long email. A *lot* of it is encapsulated in the Venn diagram both: >>> http://smalltalk.uk.to/unicode-utf8.html >>> and my Smalltalk in Small Steps blog at: >>> http://smalltalkinsmallsteps.blogspot.co.uk/2015/12/utf-8-for-cuis-pharo-and-squeak.html >>> >>> My current thinking, and understanding. >>> == >>> >>> 0) a) ASCII and ISO-8859-1 consist of characters encoded in 1 byte. >>> b) UTF-8 can encode all of those characters in 1 byte, but can >>> prefer some of them to be encoded as sequences of multiple bytes. And >>> can encode additional characters as sequences of multiple bytes. >>> >>> 1) Smalltalk has long had multiple String classes. >>> >>> 2) Any UTF16 Unicode codepoint which has a codepoint of 00nn hex >>> is encoded as a UTF-8 codepoint of nn hex. >>> >>> 3) All valid ISO-8859-1 characters have a character code between 20 >>> hex and 7E hex, or between A0 hex and FF hex. >>> https://en.wikipedia.org/wiki/ISO/IEC_8859-1 >>> >>> 4) All val
Re: [Pharo-dev] Unicode Support
Verifying assumptions is the key reason why you should documents like this out for review. Sven - Cuis is encoded with ISO 8859-15 (aka ISO Latin 9) Sven, this is *NOT* as you state, ISO 99591, (and not as I stated, 8859-1). We caught the right specification bug for the wrong reason. Juan: "Cuis: Chose not to use Squeak approach. Chose to make the base image include and use only 1-byte strings. Chose to use ISO-8859-15" I have double-checked - each character encoded in ISO Latin 15 (ISO 8859-15) is exactly the character represented by the corresponding 1-byte codepoint in Unicode to 00FF, with the following exceptions: codepoint 20ac - Euro symbol character code a4 (replaces codepoint 00a4 generic currency symbol) codepoint 0160 Latin Upper Case S with Caron character code a6 (replaces codepoint 00A6 was | Unix pipe character) codepoint 0161 Latin Lower Case s with Caron character code a8 (replaces codepoint 00A8 was dierisis) codepoint 017d Latin Upper Case Z with Caron character code b4 (replaces codepoint 00b4 was Acute accent) codepoint 017e Latin Lower Case Z with Caron character code b8 (replaces codepoint 00b8 was cedilla) codepoint 0152 Upper Case OE ligature = Ethel character code bc (replaces codepoint 00bc was 1/4 symbol) codepoint 0153 Lower Case oe ligature = ethel character code bd (replaces codepoint 00bd was 1/2 symbol) codepoint 0178 Upper Case Y diaeresis character code be (replaces codepoint 00be was 3/4 symbol) Juan - I don't suppose we could persuade you to change to ISO Latin-1 from ISO Latin-9 ? It means we could run the same 1 byte string encoding across Cuis, Squeak, Pharo, and, as far as I can make out so far, Dolphin Smalltalk and Gnu Smalltalk. The downside would be that French Y diaeresis would lose the ability to use that character, along with users of oe, OE, and s, S, z, Z with caron. Along with the Euro. https://en.wikipedia.org/wiki/ISO/IEC_8859-15. I'm confident I understand the use of UTF-8 in principal. On 7 December 2015 at 08:27, Sven Van Caekenberghe wrote: > I am sorry but one of your basic assumptions is completely wrong: > > 'Les élèves Français' encodeWith: #iso99591. > > => #[76 101 115 32 233 108 232 118 101 115 32 70 114 97 110 231 97 105 115] > > 'Les élèves Français' utf8Encoded. > > => #[76 101 115 32 195 169 108 195 168 118 101 115 32 70 114 97 110 195 167 > 97 105 115] > > ISO-9959-1 (~Latin1) is NOT AT ALL identical to UTF-8 in its upper, non-ACII > part !! > > Or shorter, $é is encoded in ISO-9959-1 as #[233], but as #[195 169] in UTF-8. > > So more than half the points you make, or the facts that you state, are thus > plain wrong. > > The only thing that is correct is that the code points are equal, but that is > not the same as the encoding ! > > From this I am inclined to conclude that you do not fundamentally understand > how UTF-8 works, which does not strike me as good basis to design something > called a UTF8String. > > Sorry. > > PS: Note also that Cuis' choice to use ISO-9959-1 only is pretty limiting in > a Unicode world. > >> On 07 Dec 2015, at 04:21, EuanM wrote: >> >> This a long email. A *lot* of it is encapsulated in the Venn diagram both: >> http://smalltalk.uk.to/unicode-utf8.html >> and my Smalltalk in Small Steps blog at: >> http://smalltalkinsmallsteps.blogspot.co.uk/2015/12/utf-8-for-cuis-pharo-and-squeak.html >> >> My current thinking, and understanding. >> == >> >> 0) a) ASCII and ISO-8859-1 consist of characters encoded in 1 byte. >> b) UTF-8 can encode all of those characters in 1 byte, but can >> prefer some of them to be encoded as sequences of multiple bytes. And >> can encode additional characters as sequences of multiple bytes. >> >> 1) Smalltalk has long had multiple String classes. >> >> 2) Any UTF16 Unicode codepoint which has a codepoint of 00nn hex >> is encoded as a UTF-8 codepoint of nn hex. >> >> 3) All valid ISO-8859-1 characters have a character code between 20 >> hex and 7E hex, or between A0 hex and FF hex. >> https://en.wikipedia.org/wiki/ISO/IEC_8859-1 >> >> 4) All valid ASCII characters have a character code between 00 hex and 7E >> hex. >> https://en.wikipedia.org/wiki/ASCII >> >> >> 5) a) All character codes which are defined within ISO-8859-1 and also >> defined within ASCII. (i.e. character codes 20 hex to 7E hex) are >> defined identically in both. >> >> b) All printable ASCII characters are defined identically in both >> ASCII and ISO-8859-1 >> >> 6) All character codes defined in ASCII (00 hex to 7E hex) are >> defined identically in Unicode UTF-8. >>
Re: [Pharo-dev] Unicode Support
Steph - I'll dig out the Fr phone book ordering from wherever it was I read about it! I thought I ghad it to hand, but I haven;t found it tonight. It can't be far away. On 5 December 2015 at 13:08, stepharo wrote: > Hi EuanM > > Le 4/12/15 12:42, EuanM a écrit : >> >> I'm currently groping my way to seeing how feature-complete our >> Unicode support is. I am doing this to establish what still needs to >> be done to provide full Unicode support. > > > this is great. Thanks for pushing this. I wrote and collected some roadmap > (analyses on different topics) > on the pharo github project feel free to add this one there. >> >> >> This seems to me to be an area where it would be best to write it >> once, and then have the same codebase incorporated into the Smalltalks >> that most share a common ancestry. >> >> I am keen to get: equality-testing for strings; sortability for >> strings which have ligatures and diacritic characters; and correct >> round-tripping of data. > > Go! > My suggestion is > start small > make steady progress > write tests > commit often :) > > Stef > > What is the french phoneBook ordering because this is the first time I hear > about it. > >> >> Call to action: >> == >> >> If you have comments on these proposals - such as "but we already have >> that facility" or "the reason we do not have these facilities is >> because they are dog-slow" - please let me know them. >> >> If you would like to help out, please let me know. >> >> If you have Unicode experience and expertise, and would like to be, or >> would be willing to be, in the 'council of experts' for this project, >> please let me know. >> >> If you have comments or ideas on anything mentioned in this email >> >> In the first instance, the initiative's website will be: >> http://smalltalk.uk.to/unicode.html >> >> I have created a SqueakSource.com project called UnicodeSupport >> >> I want to avoid re-inventing any facilities which already exist. >> Except where they prevent us reaching the goals of: >>- sortable UTF8 strings >>- sortable UTF16 strings >>- equivalence testing of 2 UTF8 strings >>- equivalence testing of 2 UTF16 strings >>- round-tripping UTF8 strings through Smalltalk >>- roundtripping UTF16 strings through Smalltalk. >> As I understand it, we have limited Unicode support atm. >> >> Current state of play >> === >> ByteString gets converted to WideString when need is automagically >> detected. >> >> Is there anything else that currently exists? >> >> Definition of Terms >> == >> A quick definition of terms before I go any further: >> >> Standard terms from the Unicode standard >> === >> a compatibility character : an additional encoding of a *normal* >> character, for compatibility and round-trip conversion purposes. For >> instance, a 1-byte encoding of a Latin character with a diacritic. >> >> Made-up terms >> >> a convenience codepoint : a single codepoint which represents an item >> that is also encoded as a string of codepoints. >> >> (I tend to use the terms compatibility character and compatibility >> codepoint interchangably. The standard only refers to them as >> compatibility characters. However, the standard is determined to >> emphasise that characters are abstract and that codepoints are >> concrete. So I think it is often more useful and productive to think >> of compatibility or convenience codepoints). >> >> a composed character : a character made up of several codepoints >> >> Unicode encoding explained >> = >> A convenience codepoint can therefore be thought of as a code point >> used for a character which also has a composed form. >> >> The way Unicode works is that sometimes you can encode a character in >> one byte, sometimes not. Sometimes you can encode it in two bytes, >> sometimes not. >> >> You can therefore have a long stream of ASCII which is single-byte >> Unicode. If there is an occasional Cyrillic or Greek character in the >> stream, it would be represented either by a compatibility character or >> by a multi-byte combination. >> >> Using compatibility characters can prevent proper sorting and >> equivalence testing. >> >> Using "pure" Unicode, ie. "normal encodings
Re: [Pharo-dev] Unicode Support
Todd, As long as others are using it, it's useful to be able to send UTF16, and to successfully import it. I like systems that play well with others. :-) On 5 December 2015 at 16:35, Todd Blanchard wrote: > would suggest that the only worthwhile encoding is UTF8 - the rest are > distractions except for being able to read and convert from other encodings > to UTF8. UTF16 is a complete waste of time. > > Read http://utf8everywhere.org/ > > I have extensive Unicode chops from around 1999 to 2004 and my experience > leads me to strongly agree with the views on that site. > > > Sent from the road > > On Dec 5, 2015, at 05:08, stepharo wrote: > > Hi EuanM > > Le 4/12/15 12:42, EuanM a écrit : > > I'm currently groping my way to seeing how feature-complete our > > Unicode support is. I am doing this to establish what still needs to > > be done to provide full Unicode support. > > > this is great. Thanks for pushing this. I wrote and collected some roadmap > (analyses on different topics) > on the pharo github project feel free to add this one there. > > > This seems to me to be an area where it would be best to write it > > once, and then have the same codebase incorporated into the Smalltalks > > that most share a common ancestry. > > > I am keen to get: equality-testing for strings; sortability for > > strings which have ligatures and diacritic characters; and correct > > round-tripping of data. > > Go! > My suggestion is >start small >make steady progress >write tests >commit often :) > > Stef > > What is the french phoneBook ordering because this is the first time I hear > about it. > > > Call to action: > > == > > > If you have comments on these proposals - such as "but we already have > > that facility" or "the reason we do not have these facilities is > > because they are dog-slow" - please let me know them. > > > If you would like to help out, please let me know. > > > If you have Unicode experience and expertise, and would like to be, or > > would be willing to be, in the 'council of experts' for this project, > > please let me know. > > > If you have comments or ideas on anything mentioned in this email > > > In the first instance, the initiative's website will be: > > http://smalltalk.uk.to/unicode.html > > > I have created a SqueakSource.com project called UnicodeSupport > > > I want to avoid re-inventing any facilities which already exist. > > Except where they prevent us reaching the goals of: > > - sortable UTF8 strings > > - sortable UTF16 strings > > - equivalence testing of 2 UTF8 strings > > - equivalence testing of 2 UTF16 strings > > - round-tripping UTF8 strings through Smalltalk > > - roundtripping UTF16 strings through Smalltalk. > > As I understand it, we have limited Unicode support atm. > > > Current state of play > > === > > ByteString gets converted to WideString when need is automagically detected. > > > Is there anything else that currently exists? > > > Definition of Terms > > == > > A quick definition of terms before I go any further: > > > Standard terms from the Unicode standard > > === > > a compatibility character : an additional encoding of a *normal* > > character, for compatibility and round-trip conversion purposes. For > > instance, a 1-byte encoding of a Latin character with a diacritic. > > > Made-up terms > > > > a convenience codepoint : a single codepoint which represents an item > > that is also encoded as a string of codepoints. > > > (I tend to use the terms compatibility character and compatibility > > codepoint interchangably. The standard only refers to them as > > compatibility characters. However, the standard is determined to > > emphasise that characters are abstract and that codepoints are > > concrete. So I think it is often more useful and productive to think > > of compatibility or convenience codepoints). > > > a composed character : a character made up of several codepoints > > > Unicode encoding explained > > = > > A convenience codepoint can therefore be thought of as a code point > > used for a character which also has a composed form. > > > The way Unicode works is that sometimes you can encode a character in > > one byte, sometimes not. Sometimes you can encode it in two bytes, > > sometimes not. > > > You can therefore have a long stream of
Re: [Pharo-dev] Unicode Support
Thanks for those pointers, Steph. I'll make sure they are on my reading list. (I have a limited weekly time-budget for Unicode work, but I expect this is a long-term project). I'll keep in touch with Steph, so any new facilities can be immediately useful to Pharo, and someone can guide them to a proper home in Pharo's Class hierarchy. For now, I've stuck stuff on my blog, http://smalltalkinsmallsteps.blogspot.co.uk/2015/12/utf-8-for-cuis-pharo-and-squeak.html in an email here and at smalltalk.uk.to/unicode-utf.html On 5 December 2015 at 13:08, stepharo wrote: > Hi EuanM > > Le 4/12/15 12:42, EuanM a écrit : >> >> I'm currently groping my way to seeing how feature-complete our >> Unicode support is. I am doing this to establish what still needs to >> be done to provide full Unicode support. > > > this is great. Thanks for pushing this. I wrote and collected some roadmap > (analyses on different topics) > on the pharo github project feel free to add this one there. >> >> >> This seems to me to be an area where it would be best to write it >> once, and then have the same codebase incorporated into the Smalltalks >> that most share a common ancestry. >> >> I am keen to get: equality-testing for strings; sortability for >> strings which have ligatures and diacritic characters; and correct >> round-tripping of data. > > Go! > My suggestion is > start small > make steady progress > write tests > commit often :) > > Stef > > What is the french phoneBook ordering because this is the first time I hear > about it. > >> >> Call to action: >> == >> >> If you have comments on these proposals - such as "but we already have >> that facility" or "the reason we do not have these facilities is >> because they are dog-slow" - please let me know them. >> >> If you would like to help out, please let me know. >> >> If you have Unicode experience and expertise, and would like to be, or >> would be willing to be, in the 'council of experts' for this project, >> please let me know. >> >> If you have comments or ideas on anything mentioned in this email >> >> In the first instance, the initiative's website will be: >> http://smalltalk.uk.to/unicode.html >> >> I have created a SqueakSource.com project called UnicodeSupport >> >> I want to avoid re-inventing any facilities which already exist. >> Except where they prevent us reaching the goals of: >>- sortable UTF8 strings >>- sortable UTF16 strings >>- equivalence testing of 2 UTF8 strings >>- equivalence testing of 2 UTF16 strings >>- round-tripping UTF8 strings through Smalltalk >>- roundtripping UTF16 strings through Smalltalk. >> As I understand it, we have limited Unicode support atm. >> >> Current state of play >> === >> ByteString gets converted to WideString when need is automagically >> detected. >> >> Is there anything else that currently exists? >> >> Definition of Terms >> == >> A quick definition of terms before I go any further: >> >> Standard terms from the Unicode standard >> === >> a compatibility character : an additional encoding of a *normal* >> character, for compatibility and round-trip conversion purposes. For >> instance, a 1-byte encoding of a Latin character with a diacritic. >> >> Made-up terms >> >> a convenience codepoint : a single codepoint which represents an item >> that is also encoded as a string of codepoints. >> >> (I tend to use the terms compatibility character and compatibility >> codepoint interchangably. The standard only refers to them as >> compatibility characters. However, the standard is determined to >> emphasise that characters are abstract and that codepoints are >> concrete. So I think it is often more useful and productive to think >> of compatibility or convenience codepoints). >> >> a composed character : a character made up of several codepoints >> >> Unicode encoding explained >> = >> A convenience codepoint can therefore be thought of as a code point >> used for a character which also has a composed form. >> >> The way Unicode works is that sometimes you can encode a character in >> one byte, sometimes not. Sometimes you can encode it in two bytes, >> sometimes not. >> >> You can therefore have a long stream of ASCII which is single-byte >> Unicode. If
Re: [Pharo-dev] Java Future
There were two issues - one was lack of handover of packages in the Catalog. The other required a reboot of Smalltalkhub On 4 December 2015 at 09:54, Marcus Denker wrote: > We are quite fast in integrating the last weeks (even months). > > *Reviewed* fixes get integrated within hours, and I try to review as much > as I can if others do not. > > To me this sounds like a fix to some other project on SmalltalkHub. T > > The thing here is that this is like gitHub: if a random Java project is > abandoned, > does Oracle step in and take over maintenance? > > Marcus > > On 04 Dec 2015, at 09:49, p...@highoctane.be wrote: > > Question: how long to drop the slice into the inbox? > > On Fri, Dec 4, 2015 at 8:51 AM, EuanM wrote: >> >> Hi Steph, >> >> As a newcomer, here is my experience with my first bug-fix: >> >> I wrote the fix in about 5 minutes. >> >> It then took several weeks to get the big-fix accepted because of >> issues with the repository and, separately, with bitrot in the list of >> maintainers. >> >> On 30 November 2015 at 16:52, stepharo wrote: >> > True help closing bug >> > Build a great library >> > Buidl a cool software >> > >> > Stef >> > >> > Le 30/11/15 04:44, EuanM a écrit : >> > >> >> We also need to concentrate on building our community. >> >> >> >> We build a better platform faster if we have more people. >> >> >> >> We build a more valuable platform if we have a wider range of valuable >> >> use cases to target. >> >> >> >> Unless and until we hit a critical mass of people joining our >> >> community, we *need* to spend some of our focus on community-building. >> >> >> >> Part of great is being able to build things to sufficient completeness >> >> *and* keep them in working order over the long haul. This is easier >> >> with more contributors. >> >> >> >> On 27 November 2015 at 21:27, Tudor Girba wrote: >> >>> >> >>> Hello everyone, >> >>> >> >>> Please stop this thread on this mailing list. We need to focus on >> >>> building a great platform. >> >>> >> >>> Cheers, >> >>> Doru >> >>> >> >>> >> >>>> On Nov 27, 2015, at 10:05 PM, EuanM wrote: >> >>>> >> >>>> First of all - is this true? Where can we read about it? >> >>>> >> >>>> I cannot find anything about this at >> >>>> https://www.oracle.com/search/press >> >>>> >> >>>> === >> >>>> >> >>>> If Oracle did make this statement, then what people have said so far >> >>>> is true. BUT... >> >>>> >> >>>> Java got about 40% of its initial momentum from IBM dumping VisualAge >> >>>> and putting all their resources into Java. >> >>>> >> >>>> Oracle are targetting this move at IBM more than anyone else. >> >>>> >> >>>> IBM will start to think about how to migrate from Java - as Oracle >> >>>> are >> >>>> telling them they will have to. (It's OUR bat and its OUR ball, and >> >>>> no-one else can play with it. Not even the Java Community). And >> >>>> IBM's coders do not pay for Java, Eclipse users do not pay for Java. >> >>>> I >> >>>> expect the licence-fee income for JREs is small. >> >>>> >> >>>> Oracle are doing one of two things - announcing that Java is for sale >> >>>> to device providers - phones (Google is the obvious buyer) or the >> >>>> impending Internet of Things (which was what Java was designed for >> >>>> originally) or announcing that no-one making an internet of things >> >>>> offering should consider Java. >> >>>> >> >>>> Yes, things live on and on in a kind of zombie state. So yes, things >> >>>> live on as long as their ecosystem does. And they gently wither and >> >>>> their ecosystem withers is a long slow drawn out spiral. Which is >> >>>> why >> >>>> we still have Cobol. >> >>>> >> >>>> People and organisations tend to move from one technology to another >> >
Re: [Pharo-dev] Java Future
Hi Steph, As a newcomer, here is my experience with my first bug-fix: I wrote the fix in about 5 minutes. It then took several weeks to get the big-fix accepted because of issues with the repository and, separately, with bitrot in the list of maintainers. On 30 November 2015 at 16:52, stepharo wrote: > True help closing bug > Build a great library > Buidl a cool software > > Stef > > Le 30/11/15 04:44, EuanM a écrit : > >> We also need to concentrate on building our community. >> >> We build a better platform faster if we have more people. >> >> We build a more valuable platform if we have a wider range of valuable >> use cases to target. >> >> Unless and until we hit a critical mass of people joining our >> community, we *need* to spend some of our focus on community-building. >> >> Part of great is being able to build things to sufficient completeness >> *and* keep them in working order over the long haul. This is easier >> with more contributors. >> >> On 27 November 2015 at 21:27, Tudor Girba wrote: >>> >>> Hello everyone, >>> >>> Please stop this thread on this mailing list. We need to focus on >>> building a great platform. >>> >>> Cheers, >>> Doru >>> >>> >>>> On Nov 27, 2015, at 10:05 PM, EuanM wrote: >>>> >>>> First of all - is this true? Where can we read about it? >>>> >>>> I cannot find anything about this at >>>> https://www.oracle.com/search/press >>>> >>>> === >>>> >>>> If Oracle did make this statement, then what people have said so far >>>> is true. BUT... >>>> >>>> Java got about 40% of its initial momentum from IBM dumping VisualAge >>>> and putting all their resources into Java. >>>> >>>> Oracle are targetting this move at IBM more than anyone else. >>>> >>>> IBM will start to think about how to migrate from Java - as Oracle are >>>> telling them they will have to. (It's OUR bat and its OUR ball, and >>>> no-one else can play with it. Not even the Java Community). And >>>> IBM's coders do not pay for Java, Eclipse users do not pay for Java. I >>>> expect the licence-fee income for JREs is small. >>>> >>>> Oracle are doing one of two things - announcing that Java is for sale >>>> to device providers - phones (Google is the obvious buyer) or the >>>> impending Internet of Things (which was what Java was designed for >>>> originally) or announcing that no-one making an internet of things >>>> offering should consider Java. >>>> >>>> Yes, things live on and on in a kind of zombie state. So yes, things >>>> live on as long as their ecosystem does. And they gently wither and >>>> their ecosystem withers is a long slow drawn out spiral. Which is why >>>> we still have Cobol. >>>> >>>> People and organisations tend to move from one technology to another >>>> in an incremental fashion. Swapping a little bit here, and a little >>>> bit there. >>>> >>>> The new target platforms are ones which >>>> 1) look like they have longevity, and >>>> 2) have a migration pathway that provides incremental steps. >>>> >>>> Offering a compelling advantage is good - but only if the steps 1) >>>> and 2) are catered to. >>>> >>>> IBM VisualAge Smalltalk is still robust, commercially available >>>> software, and VisualStudio and Gemstone continue to represent >>>> Smalltalk out to the big world of corporate development. >>>> >>>> So that's a start. >>>> >>>> Say only 5% of the Java world moves away from Java each year, as a >>>> result of this announcement. >>>> >>>> We *should* wish to take advantage of this announcement. >>>> >>>> After all, think what difference having even 0.01% of the world's Java >>>> coders moving to Smalltalk would make.How could we help that >>>> happen? >>>> >>>> Think what it would be like to have thought-leaders like Kent Beck and >>>> Ward Cunningham back in the Smalltalk fold. How could we help that >>>> happen? >>>> >>>> Think what it would be like to get back all the universities who moved >>>> from teaching OO concepts using
[Pharo-dev] Community Building [was: please name your thread]
Tudor, You say that we are talking about different mails. I hope so. "We need to focus on building a great platform." "acting is the only thing that will push us further.". I agree that action is what achieves things. To make sure the correct actions are taken, in a productive and efficient way, it can be valuable to take stock and think, periodically. It is important to carry out a variety of actions, not solely coding. Too narrow a focus on keeping a small group of people coding as fast as they can is not the fastest path to the end goal. It can easily lead to improving the platform at a slower rate than other great platforms are improving - a process of relative decay. I would like to help with community building efforts. But unless the leaders of the community also help and prioritise such efforts, they are unlikely to make any difference. There is no point gaining the interest of new people unless we have mechanisms in place to make them welcome, and put them on the path to becoming valuable contributors to the community. Small communities with low levels of resource must, to succeed, do things more efficiently than large groups with lots of funding. Currently, we lack: 1) debugged beginner's training materials. 2) community processes for getting the interest of new people 3) community processes for onboarding interested new people with the lowest loss rate 4) community processes for providing positive feedback and encouragement to people taking these actions. 5) community processes for stopping bit-rot in mature libraries and facilities - including key facilities like SqueakSource, Smalltalkhub and SqueakSource3 6) community processes to help focus resources on merging libraries into a single best-of-breed best-of-breed mature libraries. We often have two competing incomplete libraries for any given problem space, e.g. Spec/Bloc, MuTalk / SMutant 7) community processes to document the community processes 8) documented processes for bringing newcomers up to speed with "the way things are done round here" We need to take these issues seriously - they affect how fast things get done around here much more than this amount of time away from decoding Pharo-core does Closing down all discussions where these issues surface does not communicate "We welcome any action that anyone would want to undertake in this direction". Quite the reverse. We need to do more than just Smalltalk the Smalltalk - we need to walk the walk. Cheers, Euan Here is the thread I am keeping alive: On 30 November 2015 at 23:32, Tudor Girba wrote: > In any case, please name you thread appropriately. And, we should remember > that acting is the only thing that will push us further. >> On Dec 1, 2015, at 12:18 AM, EuanM wrote: >> Welcoming is, as welcoming does. >> On 30 November 2015 at 11:20, Tudor Girba wrote: >>> Increasing the community is certainly important, and we welcome any action >>> that anyone would want to undertake in this direction. >>>> On Nov 30, 2015, at 4:44 AM, EuanM wrote: >>>> We also need to concentrate on building our community. >>>> >>>> We build a better platform faster if we have more people. >>>> >>>> We build a more valuable platform if we have a wider range of valuable >>>> use cases to target. >>>> >>>> Unless and until we hit a critical mass of people joining our >>>> community, we *need* to spend some of our focus on community-building. >>>> >>>> Part of great is being able to build things to sufficient completeness >>>> *and* keep them in working order over the long haul. This is easier >>>> with more contributors. >>>>>> On Nov 27, 2015, at 10:05 PM, EuanM wrote: >>>>>> We *should* wish to take advantage of [the rumoured Java] announcement. >>>>>> >>>>>> After all, think what difference having even 0.01% of the world's Java >>>>>> coders moving to Smalltalk would make.How could we help that >>>>>> happen? [Full thread at foot of mail] On 30 November 2015 at 23:32, Tudor Girba wrote: > Hi, > > I think we are not talking about the same email. > > In any case, please name you thread appropriately. And, we should remember > that acting is the only thing that will push us further. > > Cheers, > Tudor > > >> On Dec 1, 2015, at 12:18 AM, EuanM wrote: >> >> Tudor, the email that you replied to, saying the discussion should be >> closed down, was specifically about the impacts on our community and >> how to leverage them. >> >> Welcoming is, as welcoming does. >> >> On 30 November 2015 at
Re: [Pharo-dev] Help needed: old issues issue tracker entries
I had an issue assigned against me, which I have not the time nor the knowledge to fix. (Inconstant aspect ratio of Desktop background image). Can I suggest it is given to someone who knows the Desktop GUI codebase? (If I was in a position to fix it, I would have just submitted a fix, not a bug report) On 2 December 2015 at 13:42, webwarrior wrote: > Case 16725 - Merge changes from spec github repository. > 2 subcases are resolved, 2 other need decision. Nothing time-consuming - > just decide if we integrate them or mark as wontfix. > > > Case 15927 - Menu is broken when contained in a list. > This is much more complicated, it's even not clear which class > (TransfromMorph or MenuItemMorph) is bugged. > I tried to fix it myself, but had no success. > > > > -- > View this message in context: > http://forum.world.st/Help-needed-old-issues-issue-tracker-entries-tp4864269p4864751.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >
Re: [Pharo-dev] Digest from slack to the mailing list?
I grabbed the message history manually today. The elapsed time was 2 hours! You need administrator privileges to use the API even to download the message history in a more direct way. Could someone please add me as a Slack administrator, and I will curate the message history (along with any other willing volunteers) on an ongoing basis until we have automated the history-grab and Slack has implemented threading. We also need a server on which to store the raw and the curated histories. One option would be to add new Pharo mailing lists: ones which accepted a history log per day. This would automatically give us the same replication-to-web that the emails receive. This in turn provides us with good web searchability courtesy of Google, etc. Manually handling the backlog will be time-consuming, so if someone could assist me in automating the process, that would be lovely. For any community members not yet ready to contribute code, but who have time available, this is an ideal role to gain experience of the community, to help the community, and to discover what's going on in the core development team on a day-to-day basis. On 2 December 2015 at 15:28, Gastón Dall' Oglio wrote: > You are welcome. > > Or you can use the API directly, but I do not know if it is paid or if you > are limited to 10k latest messages > https://api.slack.com/methods/channels.history > > Regards > > 2015-12-02 11:14 GMT-03:00 Esteban A. Maringolo : >> >> Thanks Gaston >> >> I created the Pharo Slack's bot for it, but I'm getting a connection >> refused error when trying to set up the SlackDigest.com integration. >> I'll try later. >> >> Regards! >> >> >> Esteban A. Maringolo >> >> >> 2015-12-02 11:05 GMT-03:00 Gastón Dall' Oglio >> : >> > Hello. >> > >> > Just a thought ... There's a automated tool for do that (I have not >> > tried >> > yet) >> > http://slackdigest.com/digest.html >> > >> > It send a DM to interested users, but maybe using Outgoing WebHooks the >> > DM >> > can be forwarded to some service to publish it. >> > >> > >> > >> > 2015-11-30 17:47 GMT-03:00 philippe.b...@highoctane.be >> > : >> >> >> >> And I've not been looking at Slack that much. >> >> >> >> Digest would be we nice indeed. >> >> >> >> Phil >> >> >> >> On Nov 30, 2015 4:53 AM, "EuanM" wrote: >> >>> >> >>> And of course, we can stop doing it manually once threading arrives. >> >>> >> >>> On 30 November 2015 at 03:52, EuanM wrote: >> >>> > I have been talking to the Slack dev team and they assure me that >> >>> > threading is on its way - as a priority. >> >>> > >> >>> > I am happy to manually curate threads if someone gets a 24hour dump >> >>> > to >> >>> > log files working. >> >>> > >> >>> > The best way to do this would be to have teams of curators per >> >>> > channel, each doing a little curation periodically on a rota per >> >>> > channel basis. >> >>> > >> >>> > This is an ideal task for people still getting up to speed with >> >>> > Pharo >> >>> > internals. It is a great way to be exposed to stuff you don't >> >>> > understand, and put your mind around it. >> >>> > >> >>> > This provide a starter slope for future contributors. >> >>> > >> >>> > On 23 November 2015 at 08:14, Yuriy Tymchuk >> >>> > wrote: >> >>> >> The problem is, that it is not that easy to create a “digest” from >> >>> >> Slack, as there is no kind of grouping. Either you have to detect >> >>> >> similar >> >>> >> words in discussion, or you have to simply export everything. I >> >>> >> don’t know >> >>> >> whether it makes sense to just compose a huge email of all >> >>> >> discussions, but >> >>> >> we can try to do that. >> >>> >> >> >>> >> Cheers. >> >>> >> Uko >> >>> >> >> >>> >>> On 23 Nov 2015, at 00:21, EuanM wrote: >> >>> >>> >> >>> >>> I agree - if we can have each 24 hours of chat archived to >> >>> >>&
Re: [Pharo-dev] Java Future
Tudor, the email that you replied to, saying the discussion should be closed down, was specifically about the impacts on our community and how to leverage them. Welcoming is, as welcoming does. On 30 November 2015 at 11:20, Tudor Girba wrote: > Hi, > > Increasing the community is certainly important, and we welcome any action > that anyone would want to undertake in this direction. > > However, talking about the future of Java does not fall in this category. > > Cheers, > Doru > > >> On Nov 30, 2015, at 4:44 AM, EuanM wrote: >> >> We also need to concentrate on building our community. >> >> We build a better platform faster if we have more people. >> >> We build a more valuable platform if we have a wider range of valuable >> use cases to target. >> >> Unless and until we hit a critical mass of people joining our >> community, we *need* to spend some of our focus on community-building. >> >> Part of great is being able to build things to sufficient completeness >> *and* keep them in working order over the long haul. This is easier >> with more contributors. >> >> On 27 November 2015 at 21:27, Tudor Girba wrote: >>> Hello everyone, >>> >>> Please stop this thread on this mailing list. We need to focus on building >>> a great platform. >>> >>> Cheers, >>> Doru >>> >>> >>>> On Nov 27, 2015, at 10:05 PM, EuanM wrote: >>>> >>>> First of all - is this true? Where can we read about it? >>>> >>>> I cannot find anything about this at >>>> https://www.oracle.com/search/press >>>> >>>> === >>>> >>>> If Oracle did make this statement, then what people have said so far >>>> is true. BUT... >>>> >>>> Java got about 40% of its initial momentum from IBM dumping VisualAge >>>> and putting all their resources into Java. >>>> >>>> Oracle are targetting this move at IBM more than anyone else. >>>> >>>> IBM will start to think about how to migrate from Java - as Oracle are >>>> telling them they will have to. (It's OUR bat and its OUR ball, and >>>> no-one else can play with it. Not even the Java Community). And >>>> IBM's coders do not pay for Java, Eclipse users do not pay for Java. I >>>> expect the licence-fee income for JREs is small. >>>> >>>> Oracle are doing one of two things - announcing that Java is for sale >>>> to device providers - phones (Google is the obvious buyer) or the >>>> impending Internet of Things (which was what Java was designed for >>>> originally) or announcing that no-one making an internet of things >>>> offering should consider Java. >>>> >>>> Yes, things live on and on in a kind of zombie state. So yes, things >>>> live on as long as their ecosystem does. And they gently wither and >>>> their ecosystem withers is a long slow drawn out spiral. Which is why >>>> we still have Cobol. >>>> >>>> People and organisations tend to move from one technology to another >>>> in an incremental fashion. Swapping a little bit here, and a little >>>> bit there. >>>> >>>> The new target platforms are ones which >>>> 1) look like they have longevity, and >>>> 2) have a migration pathway that provides incremental steps. >>>> >>>> Offering a compelling advantage is good - but only if the steps 1) >>>> and 2) are catered to. >>>> >>>> IBM VisualAge Smalltalk is still robust, commercially available >>>> software, and VisualStudio and Gemstone continue to represent >>>> Smalltalk out to the big world of corporate development. >>>> >>>> So that's a start. >>>> >>>> Say only 5% of the Java world moves away from Java each year, as a >>>> result of this announcement. >>>> >>>> We *should* wish to take advantage of this announcement. >>>> >>>> After all, think what difference having even 0.01% of the world's Java >>>> coders moving to Smalltalk would make.How could we help that >>>> happen? >>>> >>>> Think what it would be like to have thought-leaders like Kent Beck and >>>> Ward Cunningham back in the Smalltalk fold. How could we help that >>>> happen? >>>> >>>>
Re: [Pharo-dev] Java Future
We also miss a critical mass of warm bodies. Funing is very nice, don;t get me wrong. But in the absence of funding we need to be even more smart about gaining, and retaining enthusiast volunteers. On 30 November 2015 at 20:45, philippe.b...@highoctane.be wrote: > We do need more ease of integration with other software. > > * 64 bit. > * OS Process made easier. > * FFI not requiring a PhD > * Being able to use Pharo with normal text based tools (like mount an image > like a filesystem). > * Full integration with trendy tools. e.g. MongoTalk missing GridFS, > sharding, HA. > > These things are moving forward. > > I am pissed that Julia got $600 000 and we are struggling due to cash > issues. > > We do not miss brainpower. We miss being able to focus on progress because > we can't fund it well enough. > > Phil > > > > On Nov 30, 2015 12:21 PM, "Tudor Girba" wrote: >> >> Hi, >> >> Increasing the community is certainly important, and we welcome any action >> that anyone would want to undertake in this direction. >> >> However, talking about the future of Java does not fall in this category. >> >> Cheers, >> Doru >> >> >> > On Nov 30, 2015, at 4:44 AM, EuanM wrote: >> > >> > We also need to concentrate on building our community. >> > >> > We build a better platform faster if we have more people. >> > >> > We build a more valuable platform if we have a wider range of valuable >> > use cases to target. >> > >> > Unless and until we hit a critical mass of people joining our >> > community, we *need* to spend some of our focus on community-building. >> > >> > Part of great is being able to build things to sufficient completeness >> > *and* keep them in working order over the long haul. This is easier >> > with more contributors. >> > >> > On 27 November 2015 at 21:27, Tudor Girba wrote: >> >> Hello everyone, >> >> >> >> Please stop this thread on this mailing list. We need to focus on >> >> building a great platform. >> >> >> >> Cheers, >> >> Doru >> >> >> >> >> >>> On Nov 27, 2015, at 10:05 PM, EuanM wrote: >> >>> >> >>> First of all - is this true? Where can we read about it? >> >>> >> >>> I cannot find anything about this at >> >>> https://www.oracle.com/search/press >> >>> >> >>> === >> >>> >> >>> If Oracle did make this statement, then what people have said so far >> >>> is true. BUT... >> >>> >> >>> Java got about 40% of its initial momentum from IBM dumping VisualAge >> >>> and putting all their resources into Java. >> >>> >> >>> Oracle are targetting this move at IBM more than anyone else. >> >>> >> >>> IBM will start to think about how to migrate from Java - as Oracle are >> >>> telling them they will have to. (It's OUR bat and its OUR ball, and >> >>> no-one else can play with it. Not even the Java Community). And >> >>> IBM's coders do not pay for Java, Eclipse users do not pay for Java. I >> >>> expect the licence-fee income for JREs is small. >> >>> >> >>> Oracle are doing one of two things - announcing that Java is for sale >> >>> to device providers - phones (Google is the obvious buyer) or the >> >>> impending Internet of Things (which was what Java was designed for >> >>> originally) or announcing that no-one making an internet of things >> >>> offering should consider Java. >> >>> >> >>> Yes, things live on and on in a kind of zombie state. So yes, things >> >>> live on as long as their ecosystem does. And they gently wither and >> >>> their ecosystem withers is a long slow drawn out spiral. Which is why >> >>> we still have Cobol. >> >>> >> >>> People and organisations tend to move from one technology to another >> >>> in an incremental fashion. Swapping a little bit here, and a little >> >>> bit there. >> >>> >> >>> The new target platforms are ones which >> >>> 1) look like they have longevity, and >> >>> 2) have a migration pathway that provides incremental steps. >> >>> >> >>> Offeri
Re: [Pharo-dev] Does Pharo stores original author of methods?
Does git not allow additional attribute objects that it benignly stores and ignores? (I suspect I can guess the answer, but...) On 30 November 2015 at 05:55, Thierry Goubier wrote: > > Le 30 nov. 2015 5:24 AM, "EuanM" a écrit : >> >> Is there anything stopping us adding one more dictionary to each >> Monticello commit? >> >> A key of commit ids and values of author name? > > This dictionary is already there in the version metadata... The file that > generates conflicts in git. > > Thierry > >> On 24 November 2015 at 06:55, stepharo wrote: >> > +1 >> > >> > And so far Monticello is much better that having delta because you can >> > still >> > get a complete project without having to reconstruct the complete >> > snapshot from deltas. I could not imagine the amount of code we would >> > have >> > lost else. >> > Veronica in her PhD built a crawler that reconstructs all the deltas >> > based >> > on MC files. Now this is work. >> > Stef >> > >> > Le 23/11/15 17:02, Nicolas Cellier a écrit : >> > >> > It's not Monticello per se. It's the backend (the server) which is too >> > naive. >> > The .mcz must be considered as a unit of exchange between the server >> > (the >> > repository) and the client (the working copy). And please note that in >> > Monticello, it's not the only way to exchange data, it can also be a >> > .mcd (a >> > diff). >> > >> > Nothing forces the server to store the .mcz as is. That's just a naive >> > implementation. Chris Muller demonstrated how to use a database (magma) >> > as >> > backend... >> > >> > 2015-11-23 12:12 GMT+01:00 Marcus Denker : >> >> >> >> >> >> > On 22 Nov 2015, at 20:12, EuanM wrote: >> >> > >> >> > Is there any reason against amending Monticello to store and save all >> >> > author's names? >> >> >> >> It does. *If* you have all the versions… but doing anything with “all >> >> the >> >> versions” >> >> is so slow (you need to download them, unpack them…) that we do not >> >> even >> >> have >> >> a tool to show the history of a method. >> >> (getting the oldest should be simpler, if you have complete >> >> history+this >> >> .mcz is >> >> there). >> >> >> >> Monticello is meant to be a system to save the complete history of a >> >> project >> >> (if you keep all the MCZ available), but the idea to save every tiny >> >> revision as >> >> a complete snapshot, zip compresses, makes it near impossible to do >> >> anything >> >> with the history in practice. >> >> >> >> With today disks, a practical SCM would allow anyone to have the >> >> *complete* >> >> history on the local disk. Monticello does now allow that in any >> >> practical >> >> way. >> >> >> >> > >> >> > Presumably, we'd also want a tool that could extract amnders' names >> >> > all the way back to the first commit of a package? >> >> > >> >> > How many on-line Monticello repositories are in common use? >> >> > >> >> > (I know of SqueakSource.com, Smalltalkhub.com and SqueakSource3) >> >> > >> >> > Are there active administrators for each of those repositories that >> >> > would allow us to update the repositories to use the updated >> >> > Monticello? >> >> > >> >> > On 22 November 2015 at 15:42, Marcus Denker >> >> > wrote: >> >> >> >> >> >> On 20 Nov 2015, at 14:35, Denis Kudriashov >> >> >> wrote: >> >> >> >> >> >> >> >> >> 2015-11-20 14:21 GMT+01:00 Marcus Denker : >> >> >>> >> >> >>> epicea data is not stored forever. It is seasion based and the >> >> >>> shipped >> >> >>> image is >> >> >>> clean. >> >> >> >> >> >> >> >> >> But current source of this info is changes file (maybe sources). And >> >> >> I >> >> >> remember you planned to store current sources in image. And such >> >> >> information >> >> >> can be there too. >> >> >> Maybe I miss something? >> >> >> >> >> >> >> >> >> The original author is not really that much of information. And >> >> >> storing >> >> >> it >> >> >> for every method in the image would take space. >> >> >> >> >> >> As I said: the whole idea of using a source revision control system >> >> >> is >> >> >> that >> >> >> you have the *complete* history available, but >> >> >> not wasting RAM. >> >> >> >> >> >> Marcus >> >> > >> >> >> >> >> > >> > >>
Re: [Pharo-dev] Does Pharo stores original author of methods?
Is there anything stopping us adding one more dictionary to each Monticello commit? A key of commit ids and values of author name? On 24 November 2015 at 06:55, stepharo wrote: > +1 > > And so far Monticello is much better that having delta because you can still > get a complete project without having to reconstruct the complete > snapshot from deltas. I could not imagine the amount of code we would have > lost else. > Veronica in her PhD built a crawler that reconstructs all the deltas based > on MC files. Now this is work. > Stef > > Le 23/11/15 17:02, Nicolas Cellier a écrit : > > It's not Monticello per se. It's the backend (the server) which is too > naive. > The .mcz must be considered as a unit of exchange between the server (the > repository) and the client (the working copy). And please note that in > Monticello, it's not the only way to exchange data, it can also be a .mcd (a > diff). > > Nothing forces the server to store the .mcz as is. That's just a naive > implementation. Chris Muller demonstrated how to use a database (magma) as > backend... > > 2015-11-23 12:12 GMT+01:00 Marcus Denker : >> >> >> > On 22 Nov 2015, at 20:12, EuanM wrote: >> > >> > Is there any reason against amending Monticello to store and save all >> > author's names? >> >> It does. *If* you have all the versions… but doing anything with “all the >> versions” >> is so slow (you need to download them, unpack them…) that we do not even >> have >> a tool to show the history of a method. >> (getting the oldest should be simpler, if you have complete history+this >> .mcz is >> there). >> >> Monticello is meant to be a system to save the complete history of a >> project >> (if you keep all the MCZ available), but the idea to save every tiny >> revision as >> a complete snapshot, zip compresses, makes it near impossible to do >> anything >> with the history in practice. >> >> With today disks, a practical SCM would allow anyone to have the >> *complete* >> history on the local disk. Monticello does now allow that in any practical >> way. >> >> > >> > Presumably, we'd also want a tool that could extract amnders' names >> > all the way back to the first commit of a package? >> > >> > How many on-line Monticello repositories are in common use? >> > >> > (I know of SqueakSource.com, Smalltalkhub.com and SqueakSource3) >> > >> > Are there active administrators for each of those repositories that >> > would allow us to update the repositories to use the updated >> > Monticello? >> > >> > On 22 November 2015 at 15:42, Marcus Denker >> > wrote: >> >> >> >> On 20 Nov 2015, at 14:35, Denis Kudriashov >> >> wrote: >> >> >> >> >> >> 2015-11-20 14:21 GMT+01:00 Marcus Denker : >> >>> >> >>> epicea data is not stored forever. It is seasion based and the shipped >> >>> image is >> >>> clean. >> >> >> >> >> >> But current source of this info is changes file (maybe sources). And I >> >> remember you planned to store current sources in image. And such >> >> information >> >> can be there too. >> >> Maybe I miss something? >> >> >> >> >> >> The original author is not really that much of information. And storing >> >> it >> >> for every method in the image would take space. >> >> >> >> As I said: the whole idea of using a source revision control system is >> >> that >> >> you have the *complete* history available, but >> >> not wasting RAM. >> >> >> >> Marcus >> > >> >> > >
Re: [Pharo-dev] red banner and links with safari?
> On 23 November 2015 at 07:24, Stephan Eggermont wrote: > Why the link to StackOverflow? It is not our data, our community or the > possibility to influence the answers. Please delete it. > I'll continue answering questions there, we should not point people there. A link to Stack Overflow is valuable in lots of ways: 1) It is a very good code facility for questions and answers, which is exceptionally searchable via Google Bing et al. Good facilities which we do not need to write or maintain ourselves means that we can focus our effort on other things. There is no reason for us to re-invent a question-and-answer facility, or do the work of keeping it as searchable as a curated site is. 2) Why does it matter who hosts the data? It is freely and publically available, and Stack Exchange are well-funded to keep it that way over the long haul. What benefit does owning the data provide? (My general experience is that trying to control and own data leads to greater data losses over time, compared to putting them in a well-funded public repository. Does the rest of the world use github, or does it builld its own facilities? We don't own the github data. Github is not our community. Do we use Slack, or have we built our own? We don't own the Slack data. Slack is not our community. 3) We certainly *do* have the possibility to influence the answers. If we cannot influence answers to Pharo-specific questions on a public Q&A site, who can? 4) Why Stack Overflow? There was a famous bank robber in the USA who was on the FBI’s list of Ten Most Wanted Fugitives. He was asked by a reporter "Why do you rob banks?" His answer was "Because that's where the money is." Going to where there are valuable resources is a good idea. For us, the most valuable resource is developers. People who develop the Pharo platform and developers who *use* the Pharo platform. At Stack Overflow, we have the opportunity to access the hearts and minds of a *very* large group of developers. We are a very small community, chronically short of developers, documenters, testers, and many other roles. Stack Overflow is a good way to help us encourage people to express interest, and possibly even join us. Stronger, wider, deeper awareness of the benefits of our platform can only help interest in using it. Pharo is not intended as an academic pursuit. It is intended to help make a difference: to the professional lives of developers; to organisations; and to individuals who need a good way of being introduced to OO fundamentals. We make the best difference by making a difference to a large number of people and organisations. We make the best difference if a lot of people help us accelerate the speed of progress and help us complete and maintain and document our feature sets. Cheers, Euan
Re: [Pharo-dev] Digest from slack to the mailing list?
And of course, we can stop doing it manually once threading arrives. On 30 November 2015 at 03:52, EuanM wrote: > I have been talking to the Slack dev team and they assure me that > threading is on its way - as a priority. > > I am happy to manually curate threads if someone gets a 24hour dump to > log files working. > > The best way to do this would be to have teams of curators per > channel, each doing a little curation periodically on a rota per > channel basis. > > This is an ideal task for people still getting up to speed with Pharo > internals. It is a great way to be exposed to stuff you don't > understand, and put your mind around it. > > This provide a starter slope for future contributors. > > On 23 November 2015 at 08:14, Yuriy Tymchuk wrote: >> The problem is, that it is not that easy to create a “digest” from Slack, as >> there is no kind of grouping. Either you have to detect similar words in >> discussion, or you have to simply export everything. I don’t know whether it >> makes sense to just compose a huge email of all discussions, but we can try >> to do that. >> >> Cheers. >> Uko >> >>> On 23 Nov 2015, at 00:21, EuanM wrote: >>> >>> I agree - if we can have each 24 hours of chat archived to somewhere >>> that provides a free-text search, that would be very good. >>> >>> Up until now, I've been grabbing, editting and posting chats I find of >>> interest and importance to me. And it seems to lend itself to design >>> discussions. What it's not very good at, atm, is discussion >>> threading. It would be great to be able to set your typing as >>> belonging to a thread., so that when it get sucked out and archived >>> that the threads were segregated. >>> >>> Does someone have a server that could receive a text dump of all >>> recent Slack messages every 12 (or 24, or 6) hours, and then make it >>> available for indexing by Google et al, and querying (via the search >>> engines) by our dev base? >>> >>> >>> >>> >>> >>> On 22 November 2015 at 13:57, Dimitris Chloupis >>> wrote: >>>> Just to clear something up , because I see people in slack saying goodbye, >>>> or "I cant reply right now I have something to do" . Slack is not just a >>>> real time chat, it keeps messages inside a history of 10 thousand messages. >>>> So that means you can log in Slack at any time and not lose a message. >>>> There >>>> is no reason for you to be online all time, no reason to say goodbye, >>>> goodmorning , goodafternoon. You can come and go as you please the exact >>>> same way as the mailing list. >>>> >>>> The problem arises when we exceed 10k messages, the old ones get lost and I >>>> think having a place to store them is a good idea. >>>> >>>> Also what is important is in the eye of the beholder, for example I dont >>>> care about any discussion about web development , its just does not >>>> interest >>>> me or database coding or many other things. I have learned to filter out >>>> the >>>> messages I dont care about in the mailing list and just reject them. Slack >>>> is same story, I quickly glance through its history and I can search the >>>> messages that interest me using the search bar , I can star messages that I >>>> want to keep, and I can comment on existing messages / code snippets which >>>> create a thread about that message. >>>> >>>> In the end its impossible to keep the community in one place but to have a >>>> central hub that collects all the little gems can be quite useful. >>>> >>>> On Sun, Nov 22, 2015 at 3:46 PM stepharo wrote: >>>>> >>>>> Yes this would be good. >>>>> People should understand that important discussions should be via the >>>>> mailing-list. >>>>> Emails are good because you can consume them the way you want. >>>>> I simply cannot be connected all the time. So emails are good because I >>>>> can process them >>>>> when I decide. >>>>> Slack is good for more interactive session around debugger and things >>>>> like that. >>>>> >>>>> Stef >>>>> >>>>> >>>>> Le 21/11/15 18:05, Stephan Eggermont a écrit : >>>>>> Should we have a digest from slack to a mailing list? >>>>>> We are already losing messages >>>>>> >>>>>> Stephan >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> >>
Re: [Pharo-dev] Digest from slack to the mailing list?
I have been talking to the Slack dev team and they assure me that threading is on its way - as a priority. I am happy to manually curate threads if someone gets a 24hour dump to log files working. The best way to do this would be to have teams of curators per channel, each doing a little curation periodically on a rota per channel basis. This is an ideal task for people still getting up to speed with Pharo internals. It is a great way to be exposed to stuff you don't understand, and put your mind around it. This provide a starter slope for future contributors. On 23 November 2015 at 08:14, Yuriy Tymchuk wrote: > The problem is, that it is not that easy to create a “digest” from Slack, as > there is no kind of grouping. Either you have to detect similar words in > discussion, or you have to simply export everything. I don’t know whether it > makes sense to just compose a huge email of all discussions, but we can try > to do that. > > Cheers. > Uko > >> On 23 Nov 2015, at 00:21, EuanM wrote: >> >> I agree - if we can have each 24 hours of chat archived to somewhere >> that provides a free-text search, that would be very good. >> >> Up until now, I've been grabbing, editting and posting chats I find of >> interest and importance to me. And it seems to lend itself to design >> discussions. What it's not very good at, atm, is discussion >> threading. It would be great to be able to set your typing as >> belonging to a thread., so that when it get sucked out and archived >> that the threads were segregated. >> >> Does someone have a server that could receive a text dump of all >> recent Slack messages every 12 (or 24, or 6) hours, and then make it >> available for indexing by Google et al, and querying (via the search >> engines) by our dev base? >> >> >> >> >> >> On 22 November 2015 at 13:57, Dimitris Chloupis >> wrote: >>> Just to clear something up , because I see people in slack saying goodbye, >>> or "I cant reply right now I have something to do" . Slack is not just a >>> real time chat, it keeps messages inside a history of 10 thousand messages. >>> So that means you can log in Slack at any time and not lose a message. There >>> is no reason for you to be online all time, no reason to say goodbye, >>> goodmorning , goodafternoon. You can come and go as you please the exact >>> same way as the mailing list. >>> >>> The problem arises when we exceed 10k messages, the old ones get lost and I >>> think having a place to store them is a good idea. >>> >>> Also what is important is in the eye of the beholder, for example I dont >>> care about any discussion about web development , its just does not interest >>> me or database coding or many other things. I have learned to filter out the >>> messages I dont care about in the mailing list and just reject them. Slack >>> is same story, I quickly glance through its history and I can search the >>> messages that interest me using the search bar , I can star messages that I >>> want to keep, and I can comment on existing messages / code snippets which >>> create a thread about that message. >>> >>> In the end its impossible to keep the community in one place but to have a >>> central hub that collects all the little gems can be quite useful. >>> >>> On Sun, Nov 22, 2015 at 3:46 PM stepharo wrote: >>>> >>>> Yes this would be good. >>>> People should understand that important discussions should be via the >>>> mailing-list. >>>> Emails are good because you can consume them the way you want. >>>> I simply cannot be connected all the time. So emails are good because I >>>> can process them >>>> when I decide. >>>> Slack is good for more interactive session around debugger and things >>>> like that. >>>> >>>> Stef >>>> >>>> >>>> Le 21/11/15 18:05, Stephan Eggermont a écrit : >>>>> Should we have a digest from slack to a mailing list? >>>>> We are already losing messages >>>>> >>>>> Stephan >>>>> >>>>> >>>>> >>>> >>>> >>> >> > >
Re: [Pharo-dev] Java Future
We also need to concentrate on building our community. We build a better platform faster if we have more people. We build a more valuable platform if we have a wider range of valuable use cases to target. Unless and until we hit a critical mass of people joining our community, we *need* to spend some of our focus on community-building. Part of great is being able to build things to sufficient completeness *and* keep them in working order over the long haul. This is easier with more contributors. On 27 November 2015 at 21:27, Tudor Girba wrote: > Hello everyone, > > Please stop this thread on this mailing list. We need to focus on building a > great platform. > > Cheers, > Doru > > >> On Nov 27, 2015, at 10:05 PM, EuanM wrote: >> >> First of all - is this true? Where can we read about it? >> >> I cannot find anything about this at >> https://www.oracle.com/search/press >> >> === >> >> If Oracle did make this statement, then what people have said so far >> is true. BUT... >> >> Java got about 40% of its initial momentum from IBM dumping VisualAge >> and putting all their resources into Java. >> >> Oracle are targetting this move at IBM more than anyone else. >> >> IBM will start to think about how to migrate from Java - as Oracle are >> telling them they will have to. (It's OUR bat and its OUR ball, and >> no-one else can play with it. Not even the Java Community). And >> IBM's coders do not pay for Java, Eclipse users do not pay for Java. I >> expect the licence-fee income for JREs is small. >> >> Oracle are doing one of two things - announcing that Java is for sale >> to device providers - phones (Google is the obvious buyer) or the >> impending Internet of Things (which was what Java was designed for >> originally) or announcing that no-one making an internet of things >> offering should consider Java. >> >> Yes, things live on and on in a kind of zombie state. So yes, things >> live on as long as their ecosystem does. And they gently wither and >> their ecosystem withers is a long slow drawn out spiral. Which is why >> we still have Cobol. >> >> People and organisations tend to move from one technology to another >> in an incremental fashion. Swapping a little bit here, and a little >> bit there. >> >> The new target platforms are ones which >> 1) look like they have longevity, and >> 2) have a migration pathway that provides incremental steps. >> >> Offering a compelling advantage is good - but only if the steps 1) >> and 2) are catered to. >> >> IBM VisualAge Smalltalk is still robust, commercially available >> software, and VisualStudio and Gemstone continue to represent >> Smalltalk out to the big world of corporate development. >> >> So that's a start. >> >> Say only 5% of the Java world moves away from Java each year, as a >> result of this announcement. >> >> We *should* wish to take advantage of this announcement. >> >> After all, think what difference having even 0.01% of the world's Java >> coders moving to Smalltalk would make.How could we help that >> happen? >> >> Think what it would be like to have thought-leaders like Kent Beck and >> Ward Cunningham back in the Smalltalk fold. How could we help that >> happen? >> >> Think what it would be like to get back all the universities who moved >> from teaching OO concepts using Smalltalk into teaching them via Java. >> We now know almost all the ones using Smalltalk as a teaching language >> by name. Does anyone know even how many universities teach OO via >> Java?What would it be like if 5% of those universities moved to >> Smalltalk each year. How could we help that happen? >> >> Next - do we have any big brained thinkers who can see specific ways >> we can improve interoperation between Java facilities and libraries >> and the Smalltalks? For the next 12 months, we should work on Java >> integration, rather than C++ integration. We should identify the >> three best things for us to do in this regard, and make them polished >> and compelling.Who is in a position to help that happen? >> >> The final way we can take advantage help the maximum number of people >> find their way to us is to present a united community front to the >> outside world. In the same way I am both a European and a Scot, we >> need to be Smalltalkers *and*members of our individual >> Smalltalk-platform communities. >> >> How can we help make that hap
Re: [Pharo-dev] About the announcements model for SUnit
Sandi Metz on this issue of fear: https://youtu.be/npOGOmkxuio?t=1077 (You might want to back up a little after watching these 15 seconds, to get a some context) On 30 November 2015 at 00:51, EuanM wrote: > When Kent Beck was doing Smalltalk consulting, he wouldn't give SUnit > to his client corporation. > > He would get any dev group to write it themselves from the concepts. > > All of which means I don't think we need to be too precious about the > code - we don;t need to fear it :-) > > On 26 November 2015 at 11:13, Max Leske wrote: >> Hi Nicolás, >> >>> On 26 Nov 2015, at 00:43, Nicolás Papagna Maldonado >>> wrote: >>> >>> Hi everyone! >>> >>> Lately I've been playing with/digging into the announcements model for >>> SUnit, and have a couple of questions about it. >>> >>> I'm trying to understand the model and I am by no means an expert to it. Any >>> pointers/references/feedback is appreciated. >>> >>> 1) As expected TestCaseEnded is notified after a test case is run in >>> TestResult>>#runCase:, but after some tests I've noticed that the >>> announcement (which is created with the TestResult instance as collaborator) >>> is sent before the passing test case is added to the TestResult instance. >>> That means that one gets notified that a test case has been run >>> successfully, but when inspecting the result, that test case won't be there: >>> >>> runCase: aTestCase >>> [ >>> aTestCase announce: TestCaseStarted withResult: self. >>> aTestCase runCase. >>> *aTestCase announce: TestCaseEnded withResult: self. >>> self addPass: aTestCase*] >>> on: self class failure , self class skip, self class warning, >>> self class >>> error >>> do: [:ex | ex sunitAnnounce: aTestCase toResult: self] >>> >>> Is this the expected behavior? >> >> No, of course not. But what do you mean by “inspecting the result”? The >> TestResult instance should contain the finished test regardless. Say, you >> inspect the TestResult before the test has been added, then refreshing the >> inspector (or opening a new one) should correctly show the test case in the >> result because it has been added in the mean time. >> >> I guess that switching those two statements wouldn’t hurt though. >> >>> >>> 2) When a test case does not pass (for whatever reason), the failure is >>> handled and the TestResult instance is updated, but a TestCaseEnded >>> announcement is not sent. So there's a chance that you'd get a >>> TestCaseStarted announcement, but never receive a TestCaseEnded announcement >>> if it didn't pass: >>> >>> runCase: aTestCase >>> [ >>> *aTestCase announce: TestCaseStarted withResult: self.* >>> aTestCase runCase. >>> aTestCase announce: TestCaseEnded withResult: self. >>> self addPass: aTestCase] >>> on: self class failure , self class skip, self class warning, >>> self class >>> error >>> do: [:ex | *ex sunitAnnounce: aTestCase toResult: self*] >>> >>> Is this the expected behavior? >> >> I agree. TestCaseEnded should be announced in all cases. >> >>> >>> 3) When a TestSuiteEnded is announced (TestResult>>#updateResultsInHistory), >>> the announcement instance is created passing in the TestCase subclass as >>> result. So, when sending #testResult to the annoucement, one does not get a >>> TestResult instance (as expected) but the TestCase subclass. >>> >>> updateResultsInHistory >>> |classesToNotify| >>> classesToNotify:= Set new. >>> #(#passed #failures #errors) do: [ :status | >>> (self perform: status) do: [ :testCase | >>> classesToNotify add:testCase class. >>> self class updateTestHistoryFor: testCase status: >>> status ] ]. >>> *classesToNotify do:[:cl | * >>> cl historyAnnouncer announce: (*TestSuiteEnded result: cl*)] >> >> That should probably be “TestSuiteEnded testCase: cl”. If you look at the >> subscribers to TestSuiteEnded you’ll see that #result is used to retrieve >> the test case. So those senders would need to be updated. but yes, since >> there is a #testCase: selector it’s pretty bad that the selector used
Re: [Pharo-dev] About the announcements model for SUnit
When Kent Beck was doing Smalltalk consulting, he wouldn't give SUnit to his client corporation. He would get any dev group to write it themselves from the concepts. All of which means I don't think we need to be too precious about the code - we don;t need to fear it :-) On 26 November 2015 at 11:13, Max Leske wrote: > Hi Nicolás, > >> On 26 Nov 2015, at 00:43, Nicolás Papagna Maldonado >> wrote: >> >> Hi everyone! >> >> Lately I've been playing with/digging into the announcements model for >> SUnit, and have a couple of questions about it. >> >> I'm trying to understand the model and I am by no means an expert to it. Any >> pointers/references/feedback is appreciated. >> >> 1) As expected TestCaseEnded is notified after a test case is run in >> TestResult>>#runCase:, but after some tests I've noticed that the >> announcement (which is created with the TestResult instance as collaborator) >> is sent before the passing test case is added to the TestResult instance. >> That means that one gets notified that a test case has been run >> successfully, but when inspecting the result, that test case won't be there: >> >> runCase: aTestCase >> [ >> aTestCase announce: TestCaseStarted withResult: self. >> aTestCase runCase. >> *aTestCase announce: TestCaseEnded withResult: self. >> self addPass: aTestCase*] >> on: self class failure , self class skip, self class warning, >> self class >> error >> do: [:ex | ex sunitAnnounce: aTestCase toResult: self] >> >> Is this the expected behavior? > > No, of course not. But what do you mean by “inspecting the result”? The > TestResult instance should contain the finished test regardless. Say, you > inspect the TestResult before the test has been added, then refreshing the > inspector (or opening a new one) should correctly show the test case in the > result because it has been added in the mean time. > > I guess that switching those two statements wouldn’t hurt though. > >> >> 2) When a test case does not pass (for whatever reason), the failure is >> handled and the TestResult instance is updated, but a TestCaseEnded >> announcement is not sent. So there's a chance that you'd get a >> TestCaseStarted announcement, but never receive a TestCaseEnded announcement >> if it didn't pass: >> >> runCase: aTestCase >> [ >> *aTestCase announce: TestCaseStarted withResult: self.* >> aTestCase runCase. >> aTestCase announce: TestCaseEnded withResult: self. >> self addPass: aTestCase] >> on: self class failure , self class skip, self class warning, >> self class >> error >> do: [:ex | *ex sunitAnnounce: aTestCase toResult: self*] >> >> Is this the expected behavior? > > I agree. TestCaseEnded should be announced in all cases. > >> >> 3) When a TestSuiteEnded is announced (TestResult>>#updateResultsInHistory), >> the announcement instance is created passing in the TestCase subclass as >> result. So, when sending #testResult to the annoucement, one does not get a >> TestResult instance (as expected) but the TestCase subclass. >> >> updateResultsInHistory >> |classesToNotify| >> classesToNotify:= Set new. >> #(#passed #failures #errors) do: [ :status | >> (self perform: status) do: [ :testCase | >> classesToNotify add:testCase class. >> self class updateTestHistoryFor: testCase status: >> status ] ]. >> *classesToNotify do:[:cl | * >> cl historyAnnouncer announce: (*TestSuiteEnded result: cl*)] > > That should probably be “TestSuiteEnded testCase: cl”. If you look at the > subscribers to TestSuiteEnded you’ll see that #result is used to retrieve the > test case. So those senders would need to be updated. but yes, since there is > a #testCase: selector it’s pretty bad that the selector used is #result:. > >> >> 4) I've read an old post about using a Dictionary instead of storing the >> TestResult instance as history, and it seemed like that was the intended >> design. The only issue I see there is that there could be potentially >> duplicated code in writing the interpretation of that dictionary (ie. >> #passed, #failures, #defects, etc..). Has anyone worked with TestCase >> results history before? if So, which was your approach to do it? >> >> Cheers, >> Nico PM >> >> > > Thanks for looking at that code! It’s been lying around for ages and everyone > fears it (at least that’s my impression :) ). > > Cheers, > Max > >> >> >> >> -- >> View this message in context: >> http://forum.world.st/About-the-announcements-model-for-SUnit-tp4863569.html >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> > >
Re: [Pharo-dev] Java Future
First of all - is this true? Where can we read about it? I cannot find anything about this at https://www.oracle.com/search/press === If Oracle did make this statement, then what people have said so far is true. BUT... Java got about 40% of its initial momentum from IBM dumping VisualAge and putting all their resources into Java. Oracle are targetting this move at IBM more than anyone else. IBM will start to think about how to migrate from Java - as Oracle are telling them they will have to. (It's OUR bat and its OUR ball, and no-one else can play with it. Not even the Java Community). And IBM's coders do not pay for Java, Eclipse users do not pay for Java. I expect the licence-fee income for JREs is small. Oracle are doing one of two things - announcing that Java is for sale to device providers - phones (Google is the obvious buyer) or the impending Internet of Things (which was what Java was designed for originally) or announcing that no-one making an internet of things offering should consider Java. Yes, things live on and on in a kind of zombie state. So yes, things live on as long as their ecosystem does. And they gently wither and their ecosystem withers is a long slow drawn out spiral. Which is why we still have Cobol. People and organisations tend to move from one technology to another in an incremental fashion. Swapping a little bit here, and a little bit there. The new target platforms are ones which 1) look like they have longevity, and 2) have a migration pathway that provides incremental steps. Offering a compelling advantage is good - but only if the steps 1) and 2) are catered to. IBM VisualAge Smalltalk is still robust, commercially available software, and VisualStudio and Gemstone continue to represent Smalltalk out to the big world of corporate development. So that's a start. Say only 5% of the Java world moves away from Java each year, as a result of this announcement. We *should* wish to take advantage of this announcement. After all, think what difference having even 0.01% of the world's Java coders moving to Smalltalk would make.How could we help that happen? Think what it would be like to have thought-leaders like Kent Beck and Ward Cunningham back in the Smalltalk fold. How could we help that happen? Think what it would be like to get back all the universities who moved from teaching OO concepts using Smalltalk into teaching them via Java. We now know almost all the ones using Smalltalk as a teaching language by name. Does anyone know even how many universities teach OO via Java?What would it be like if 5% of those universities moved to Smalltalk each year. How could we help that happen? Next - do we have any big brained thinkers who can see specific ways we can improve interoperation between Java facilities and libraries and the Smalltalks? For the next 12 months, we should work on Java integration, rather than C++ integration. We should identify the three best things for us to do in this regard, and make them polished and compelling.Who is in a position to help that happen? The final way we can take advantage help the maximum number of people find their way to us is to present a united community front to the outside world. In the same way I am both a European and a Scot, we need to be Smalltalkers *and*members of our individual Smalltalk-platform communities. How can we help make that happen? This is not a silver bullet. It's going to cause a long-term trend in events, not a sudden abrupt change. But it will have a real, if gradual effect. (assuming that Equally, it is not something we should ignore. It is something we should make use of. We need to put effort into raising our profile over the next 6 months. On 25 November 2015 at 19:51, Casimiro - GMAIL wrote: > Em 25-11-2015 17:21, Nicolas Anquetil escreveu: > > > > On 25/11/2015 19:55, Jimmie Houchin wrote: > > Much truth in what you say. However, what Oracle choose to invest its money, > time, personnel resource into Java does affect its present and future. It > has a great affect. But it isn't the whole story. Java has enough momentum > in what already exists in the language and vm and what has been release > under its license, for businesses to keep going for some time with only what > currently exists. > > Cobol is still alive (and well) after > 50 years. > You can expect Java programmers to find jobs for many years yet to come > :-) > > nicolas > > -- > Nicolas Anquetil > RMod team -- Inria Lille > > 1st: Java is extremely profitable. Each android phone, each android TV, each > android embedded system pays copyrights to Oracle. > 2nd: Much of current cloud infrastructure depends on java. > 3rd: Java is already obsolete, like Frotran, Cobol, C, C++. It will continue > to be used by same reasons these languages are used. > > IMHO, discussing java is not profitable. Better to discuss things to be than > talk about things that alre
Re: [Pharo-dev] Does Pharo stores original author of methods?
I did not mean storing all versions. I mean storing all authors of previous veesions. On 23 Nov 2015 11:13, "Marcus Denker" wrote: > > > On 22 Nov 2015, at 20:12, EuanM wrote: > > > > Is there any reason against amending Monticello to store and save all > > author's names? > > It does. *If* you have all the versions… but doing anything with “all the > versions” > is so slow (you need to download them, unpack them…) that we do not even > have > a tool to show the history of a method. > (getting the oldest should be simpler, if you have complete history+this > .mcz is > there). > > Monticello is meant to be a system to save the complete history of a > project > (if you keep all the MCZ available), but the idea to save every tiny > revision as > a complete snapshot, zip compresses, makes it near impossible to do > anything > with the history in practice. > > With today disks, a practical SCM would allow anyone to have the *complete* > history on the local disk. Monticello does now allow that in any practical > way. > > > > > Presumably, we'd also want a tool that could extract amnders' names > > all the way back to the first commit of a package? > > > > How many on-line Monticello repositories are in common use? > > > > (I know of SqueakSource.com, Smalltalkhub.com and SqueakSource3) > > > > Are there active administrators for each of those repositories that > > would allow us to update the repositories to use the updated > > Monticello? > > > > On 22 November 2015 at 15:42, Marcus Denker > wrote: > >> > >> On 20 Nov 2015, at 14:35, Denis Kudriashov > wrote: > >> > >> > >> 2015-11-20 14:21 GMT+01:00 Marcus Denker : > >>> > >>> epicea data is not stored forever. It is seasion based and the shipped > >>> image is > >>> clean. > >> > >> > >> But current source of this info is changes file (maybe sources). And I > >> remember you planned to store current sources in image. And such > information > >> can be there too. > >> Maybe I miss something? > >> > >> > >> The original author is not really that much of information. And storing > it > >> for every method in the image would take space. > >> > >> As I said: the whole idea of using a source revision control system is > that > >> you have the *complete* history available, but > >> not wasting RAM. > >> > >> Marcus > > > > >
Re: [Pharo-dev] Digest from slack to the mailing list?
I agree - if we can have each 24 hours of chat archived to somewhere that provides a free-text search, that would be very good. Up until now, I've been grabbing, editting and posting chats I find of interest and importance to me. And it seems to lend itself to design discussions. What it's not very good at, atm, is discussion threading. It would be great to be able to set your typing as belonging to a thread., so that when it get sucked out and archived that the threads were segregated. Does someone have a server that could receive a text dump of all recent Slack messages every 12 (or 24, or 6) hours, and then make it available for indexing by Google et al, and querying (via the search engines) by our dev base? On 22 November 2015 at 13:57, Dimitris Chloupis wrote: > Just to clear something up , because I see people in slack saying goodbye, > or "I cant reply right now I have something to do" . Slack is not just a > real time chat, it keeps messages inside a history of 10 thousand messages. > So that means you can log in Slack at any time and not lose a message. There > is no reason for you to be online all time, no reason to say goodbye, > goodmorning , goodafternoon. You can come and go as you please the exact > same way as the mailing list. > > The problem arises when we exceed 10k messages, the old ones get lost and I > think having a place to store them is a good idea. > > Also what is important is in the eye of the beholder, for example I dont > care about any discussion about web development , its just does not interest > me or database coding or many other things. I have learned to filter out the > messages I dont care about in the mailing list and just reject them. Slack > is same story, I quickly glance through its history and I can search the > messages that interest me using the search bar , I can star messages that I > want to keep, and I can comment on existing messages / code snippets which > create a thread about that message. > > In the end its impossible to keep the community in one place but to have a > central hub that collects all the little gems can be quite useful. > > On Sun, Nov 22, 2015 at 3:46 PM stepharo wrote: >> >> Yes this would be good. >> People should understand that important discussions should be via the >> mailing-list. >> Emails are good because you can consume them the way you want. >> I simply cannot be connected all the time. So emails are good because I >> can process them >> when I decide. >> Slack is good for more interactive session around debugger and things >> like that. >> >> Stef >> >> >> Le 21/11/15 18:05, Stephan Eggermont a écrit : >> > Should we have a digest from slack to a mailing list? >> > We are already losing messages >> > >> > Stephan >> > >> > >> > >> >> >
Re: [Pharo-dev] Does Pharo stores original author of methods?
Is there any reason against amending Monticello to store and save all author's names? Presumably, we'd also want a tool that could extract amnders' names all the way back to the first commit of a package? How many on-line Monticello repositories are in common use? (I know of SqueakSource.com, Smalltalkhub.com and SqueakSource3) Are there active administrators for each of those repositories that would allow us to update the repositories to use the updated Monticello? On 22 November 2015 at 15:42, Marcus Denker wrote: > > On 20 Nov 2015, at 14:35, Denis Kudriashov wrote: > > > 2015-11-20 14:21 GMT+01:00 Marcus Denker : >> >> epicea data is not stored forever. It is seasion based and the shipped >> image is >> clean. > > > But current source of this info is changes file (maybe sources). And I > remember you planned to store current sources in image. And such information > can be there too. > Maybe I miss something? > > > The original author is not really that much of information. And storing it > for every method in the image would take space. > > As I said: the whole idea of using a source revision control system is that > you have the *complete* history available, but > not wasting RAM. > > Marcus
Re: [Pharo-dev] Preparing for the (already here) future world of multi-core PCs
There are also uses that don't involve the GPU - any headless server use, e.g. running a pack of headless Seasides. Ways to deal with the machine becoming IO bound is definitely one of the key issues. I'm not saying anything is preventing it - I'm saying that one of the key enablers are tools to support it. On 19 November 2015 at 12:58, Dimitris Chloupis wrote: > Now days the real CPU is the GPU. Most of the acceleration and parrarel > computing happens in there. > > Eventhough my fellow pharo collogues are mostly purists that prefer > everything implemented in Pharo I am a parasitist preffering to leach off > any technology I can find, my favourite choice being python. Its possible to > use my socket bridge to bridge pharo with python in a few dozen lines of > code to access to 2 python libraries, multiprocessing and foremost PyCuda so > you can both take advantage the multiple cores of a CPU and an GPU though > GPU should be your prime focus if you want considerably speed ups to your > code. > > So none stops a pharoers making code that runs on multiple CPU and GPUs , > all it takes is a bit of imagination and an open mind. Sometimes the > quickest way to reach a goal is not a straight line . > > The truth however is even I that works with 3d graphics I find myself barely > needing 1 CPU core, so you need to first make sure that you need such a > feature before implementing it. > > On Thu, Nov 19, 2015 at 4:19 AM EuanM wrote: >> >> I agree that parallelism and concurrency are different things. >> >> For easy parallelism : >> - a multi-VM version of something like PharoLauncher. >> - tools for tailor each VM + Image >> - tools to manage and track each running VM + Image. >> - tolls to try to mak sure that different running VMs and images have >> their own core, and that VMs can be closed down so that VMs never are >> sharing (unless you want them to) >> >> All we need to do is make sure that the VM and image don't have >> baked-in assumptions about being the only VM on the physical machine >> baked in to each VM and the Smalltalk above it.) >> >> The task for the end-user app developers then becomes seeing what >> bundles of functionality are sufficiently decoupled from the others >> that they can be set adrift in their own VM. >> >> (I'm even starting to think of reinventing the multi-user server. A >> single 16 core PC, with 16 4-core Raspberry Pis connected, and each >> RPi's user taking control of a single app on a single VM single core >> on the PC). >> >> (Then you could have a quite a decent network for $140 per workstation >> (PiCEED + keyboard + mouse) , and one fast laptop as the central >> server Cheap, and easy to transport to remote locations. (But I >> digress) >> >> >> Concurrency is a deeper and harder problem for a Smalltalk, I agree. >> >> >> >> On 18 November 2015 at 23:36, Michael J. Forster >> wrote: >> > This is no small issue, nor a single one. >> > >> > Be careful to distinguish concurrency from parallelism. See Rob Pike's >> > talk/slides on this. >> > >> > Note that many systems can benefit from a concurrent design--even on a >> > single core, where no parallel execution is possible--because the >> > problem is >> > inherently concurrent; note how effectively shared-nothing approaches >> > with >> > Erlang, Go, or Scala/Akka have been used in such domains. >> > >> > In other domains, parallelism--especially nested data parallelism--is >> > more >> > important than concurrency (see >> > >> > http://yosefk.com/blog/parallelism-and-concurrency-need-different-tools.html). >> > The Haskell and other communities have been exploring this with shared >> > memory approaches like STM. >> > >> > So, to better use the slowing but increasing number of cores in today's >> > hardware, we need to understand the many very different use cases and >> > approaches. The lowest-hanging fruit in the Pharo/Squeak world might be >> > to >> > rework the vm and process scheduler to support massive numbers of >> > lighter >> > weight processes similar to Erlang. Check out Andrew Blacks "Erlang in >> > Pharo", http://www.squeaksource.com/Erlang.html. >> > >> > Best, >> > >> > Mike >> > >> > >> > >> > >> > -- >> > View this message in context: >> > http://forum.world.st/Preparing-for-the-already-here-future-world-of-multi-core-PCs-tp4861824p4861852.html >> > Sent from the Pharo Smalltalk Developers mailing list archive at >> > Nabble.com. >> > >> >
Re: [Pharo-dev] Preparing for the (already here) future world of multi-core PCs
Maybe a 'pack' of Seasides is the wrong collective. A 'shoreline' of Seasides? A 'coast'? On 19 November 2015 at 15:22, EuanM wrote: > There are also uses that don't involve the GPU - any headless server > use, e.g. running a pack of headless Seasides. > > Ways to deal with the machine becoming IO bound is definitely one of > the key issues. > > I'm not saying anything is preventing it - I'm saying that one of the > key enablers are tools to support it. > > On 19 November 2015 at 12:58, Dimitris Chloupis wrote: >> Now days the real CPU is the GPU. Most of the acceleration and parrarel >> computing happens in there. >> >> Eventhough my fellow pharo collogues are mostly purists that prefer >> everything implemented in Pharo I am a parasitist preffering to leach off >> any technology I can find, my favourite choice being python. Its possible to >> use my socket bridge to bridge pharo with python in a few dozen lines of >> code to access to 2 python libraries, multiprocessing and foremost PyCuda so >> you can both take advantage the multiple cores of a CPU and an GPU though >> GPU should be your prime focus if you want considerably speed ups to your >> code. >> >> So none stops a pharoers making code that runs on multiple CPU and GPUs , >> all it takes is a bit of imagination and an open mind. Sometimes the >> quickest way to reach a goal is not a straight line . >> >> The truth however is even I that works with 3d graphics I find myself barely >> needing 1 CPU core, so you need to first make sure that you need such a >> feature before implementing it. >> >> On Thu, Nov 19, 2015 at 4:19 AM EuanM wrote: >>> >>> I agree that parallelism and concurrency are different things. >>> >>> For easy parallelism : >>> - a multi-VM version of something like PharoLauncher. >>> - tools for tailor each VM + Image >>> - tools to manage and track each running VM + Image. >>> - tolls to try to mak sure that different running VMs and images have >>> their own core, and that VMs can be closed down so that VMs never are >>> sharing (unless you want them to) >>> >>> All we need to do is make sure that the VM and image don't have >>> baked-in assumptions about being the only VM on the physical machine >>> baked in to each VM and the Smalltalk above it.) >>> >>> The task for the end-user app developers then becomes seeing what >>> bundles of functionality are sufficiently decoupled from the others >>> that they can be set adrift in their own VM. >>> >>> (I'm even starting to think of reinventing the multi-user server. A >>> single 16 core PC, with 16 4-core Raspberry Pis connected, and each >>> RPi's user taking control of a single app on a single VM single core >>> on the PC). >>> >>> (Then you could have a quite a decent network for $140 per workstation >>> (PiCEED + keyboard + mouse) , and one fast laptop as the central >>> server Cheap, and easy to transport to remote locations. (But I >>> digress) >>> >>> >>> Concurrency is a deeper and harder problem for a Smalltalk, I agree. >>> >>> >>> >>> On 18 November 2015 at 23:36, Michael J. Forster >>> wrote: >>> > This is no small issue, nor a single one. >>> > >>> > Be careful to distinguish concurrency from parallelism. See Rob Pike's >>> > talk/slides on this. >>> > >>> > Note that many systems can benefit from a concurrent design--even on a >>> > single core, where no parallel execution is possible--because the >>> > problem is >>> > inherently concurrent; note how effectively shared-nothing approaches >>> > with >>> > Erlang, Go, or Scala/Akka have been used in such domains. >>> > >>> > In other domains, parallelism--especially nested data parallelism--is >>> > more >>> > important than concurrency (see >>> > >>> > http://yosefk.com/blog/parallelism-and-concurrency-need-different-tools.html). >>> > The Haskell and other communities have been exploring this with shared >>> > memory approaches like STM. >>> > >>> > So, to better use the slowing but increasing number of cores in today's >>> > hardware, we need to understand the many very different use cases and >>> > approaches. The lowest-hanging fruit in the Pharo/Squeak world might be >>> > to >>> > rework the vm and process scheduler to support massive numbers of >>> > lighter >>> > weight processes similar to Erlang. Check out Andrew Blacks "Erlang in >>> > Pharo", http://www.squeaksource.com/Erlang.html. >>> > >>> > Best, >>> > >>> > Mike >>> > >>> > >>> > >>> > >>> > -- >>> > View this message in context: >>> > http://forum.world.st/Preparing-for-the-already-here-future-world-of-multi-core-PCs-tp4861824p4861852.html >>> > Sent from the Pharo Smalltalk Developers mailing list archive at >>> > Nabble.com. >>> > >>> >>
Re: [Pharo-dev] Preparing for the (already here) future world of multi-core PCs
I agree that parallelism and concurrency are different things. For easy parallelism : - a multi-VM version of something like PharoLauncher. - tools for tailor each VM + Image - tools to manage and track each running VM + Image. - tolls to try to mak sure that different running VMs and images have their own core, and that VMs can be closed down so that VMs never are sharing (unless you want them to) All we need to do is make sure that the VM and image don't have baked-in assumptions about being the only VM on the physical machine baked in to each VM and the Smalltalk above it.) The task for the end-user app developers then becomes seeing what bundles of functionality are sufficiently decoupled from the others that they can be set adrift in their own VM. (I'm even starting to think of reinventing the multi-user server. A single 16 core PC, with 16 4-core Raspberry Pis connected, and each RPi's user taking control of a single app on a single VM single core on the PC). (Then you could have a quite a decent network for $140 per workstation (PiCEED + keyboard + mouse) , and one fast laptop as the central server Cheap, and easy to transport to remote locations. (But I digress) Concurrency is a deeper and harder problem for a Smalltalk, I agree. On 18 November 2015 at 23:36, Michael J. Forster wrote: > This is no small issue, nor a single one. > > Be careful to distinguish concurrency from parallelism. See Rob Pike's > talk/slides on this. > > Note that many systems can benefit from a concurrent design--even on a > single core, where no parallel execution is possible--because the problem is > inherently concurrent; note how effectively shared-nothing approaches with > Erlang, Go, or Scala/Akka have been used in such domains. > > In other domains, parallelism--especially nested data parallelism--is more > important than concurrency (see > http://yosefk.com/blog/parallelism-and-concurrency-need-different-tools.html). > The Haskell and other communities have been exploring this with shared > memory approaches like STM. > > So, to better use the slowing but increasing number of cores in today's > hardware, we need to understand the many very different use cases and > approaches. The lowest-hanging fruit in the Pharo/Squeak world might be to > rework the vm and process scheduler to support massive numbers of lighter > weight processes similar to Erlang. Check out Andrew Blacks "Erlang in > Pharo", http://www.squeaksource.com/Erlang.html. > > Best, > > Mike > > > > > -- > View this message in context: > http://forum.world.st/Preparing-for-the-already-here-future-world-of-multi-core-PCs-tp4861824p4861852.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >
[Pharo-dev] Preparing for the (already here) future world of multi-core PCs
(And yes, I know it's actually here already). Now that clock-speed rises have stalled, basically forever, desktop and laptop PCs are growing ever-increasing numbers of cores in their CPU chips, Is there design and conceptualisations work going on to see how Pharo will deal with providing increased access to the additional processing power? One thing I have been thinking about is a set of co-operating Pharo VMs. But given memory and storage are shared, this may not provide as large a benefit as we'd like. Or moving Pharo into being having multiple native-threads, and taking Pharo into a concurrency route. Or - whatever it is I am too ignorant to see. This all strikes me (like the way Smalltalk is extending its system boundary out onto the web with Monticello, Pharo is extending that via the Configuration Browser and Versionner) as a way Pharo could build on Smalltalk, while becoming its own thing. (as opposed to being a Smalltalk with a very big set of classes). Is there thought work going on in this area yet? DabbleDB had a system of running multiple VMs on a server, and hot-swapping them in and out depending on their CPU loading. Did that ever get developed intop a more generally-useful facility?
Re: [Pharo-dev] keyboard events in the windows VM
I'm happy to test on Windows 7, and on Raspbian Linux (Although Raspbian Linux runs Pharo UI events slo-o-owly, so I am not the best person to do the Linux testing) On 12 November 2015 at 15:42, EuanM wrote: > I think anything that makes a consistent UI to Pharo for users on > different platforms is a good thing. > > However, I do not know what the downside-effects of this change are. > > The key thing is to capture all breaks caused by the changed, so they > can be coded through or around. And ensure that the test results are > viewed with at least the same importance as the automated Jenkins CI > test results. > > I do not know the extent that the Jenkins CI tests actually simulate > user keyboard input, so... (Pharo pseudocode for comic effect and > clarity) > > We can write Jenkins tests that simulate user input >ifTrue: [ we should do so ]. >ifFalse: [ > we should >write a canonical set of regression test scripts for human > users to follow . > we should >do: [:eachPlatformSupportedByPharo | > run the tests in which humans use keyboard tasks ] . > we should >capture the results ; >and feed them into automated the regression tests results database > ] > > > On 12 November 2015 at 08:35, Nicolai Hess wrote: >> A short overview: >> >> With Ctrl-Key pressed, >> >> some keyboard events don't generate smalltalk keystrokes (EventKeyChar) >> ctrl+tab, ctrl+1, ctrl+2, ..., ctrl+0, ctrl+Tab, ctrl+m >> >> for some keyboard events there are only key down and key up events (from >> windows) but the vm "generates" a keypress (EventKeyChar) event >> ctrl+Home, ctrl+End, ctrl+PageUp, ... >> >> But the key value , char code and ctrl flag for this generated events, make >> them undistinguishable from other ctrl+key shortcuts >> ctrl+a = ctrl+Home, ctrl+d = ctrl+End, ctrl+k=ctrl+PageUp,... >> >> And one key (ctrl+Enter) creates two EventKeyChar events one "normal" and >> one that is generated from the vm >> one with keyvalue 10 and one with 13. >> >> And the keycode for char like "a","b", ..., are different if you they are >> typed with or without ctrl-key >> >> just key "a": >> keycode: >> 65 (keydown event) >> 97 (keyvalue/charcode event) (65 if you press shift key) >> 65 (keyup event) >> >> with ctrl key pressed: >> keycode >> 65 (keydown event) >> 1 (keyvalue/charcode event) >> 65 (keyup event) >> >> >> I would like to change this, that means: >> >> generate EventKeyChar events for >> ctrl+1, ctrl+2, ..., ctrl+Tab, ctrl+m >> >> remove the double key event for ctrl+Enter >> >> and adopt the behavior of the linux vm, for keyValue, charCode values for >> events like >> ctrl+a, ctrl+home, ... >> >> for example, the linux vm generates event buffer values: >> #(2 7329656 1 0 2 65 0 1) for ctrl+a (keyValue 1/charCode 65) >> but >> #(2 7329656 1 0 2 1 0 1) for ctrl+home (keyValue 1/charCode 1) >> >> this may need some changes on the image side. For example, in Pharo we >> have some special handling that adds "96" to the keyValue for keystrokes >> with ctrl-key). >> >> What do you think? >> >> >> >> nicolai >>
Re: [Pharo-dev] keyboard events in the windows VM
I think anything that makes a consistent UI to Pharo for users on different platforms is a good thing. However, I do not know what the downside-effects of this change are. The key thing is to capture all breaks caused by the changed, so they can be coded through or around. And ensure that the test results are viewed with at least the same importance as the automated Jenkins CI test results. I do not know the extent that the Jenkins CI tests actually simulate user keyboard input, so... (Pharo pseudocode for comic effect and clarity) We can write Jenkins tests that simulate user input ifTrue: [ we should do so ]. ifFalse: [ we should write a canonical set of regression test scripts for human users to follow . we should do: [:eachPlatformSupportedByPharo | run the tests in which humans use keyboard tasks ] . we should capture the results ; and feed them into automated the regression tests results database ] On 12 November 2015 at 08:35, Nicolai Hess wrote: > A short overview: > > With Ctrl-Key pressed, > > some keyboard events don't generate smalltalk keystrokes (EventKeyChar) > ctrl+tab, ctrl+1, ctrl+2, ..., ctrl+0, ctrl+Tab, ctrl+m > > for some keyboard events there are only key down and key up events (from > windows) but the vm "generates" a keypress (EventKeyChar) event > ctrl+Home, ctrl+End, ctrl+PageUp, ... > > But the key value , char code and ctrl flag for this generated events, make > them undistinguishable from other ctrl+key shortcuts > ctrl+a = ctrl+Home, ctrl+d = ctrl+End, ctrl+k=ctrl+PageUp,... > > And one key (ctrl+Enter) creates two EventKeyChar events one "normal" and > one that is generated from the vm > one with keyvalue 10 and one with 13. > > And the keycode for char like "a","b", ..., are different if you they are > typed with or without ctrl-key > > just key "a": > keycode: > 65 (keydown event) > 97 (keyvalue/charcode event) (65 if you press shift key) > 65 (keyup event) > > with ctrl key pressed: > keycode > 65 (keydown event) > 1 (keyvalue/charcode event) > 65 (keyup event) > > > I would like to change this, that means: > > generate EventKeyChar events for > ctrl+1, ctrl+2, ..., ctrl+Tab, ctrl+m > > remove the double key event for ctrl+Enter > > and adopt the behavior of the linux vm, for keyValue, charCode values for > events like > ctrl+a, ctrl+home, ... > > for example, the linux vm generates event buffer values: > #(2 7329656 1 0 2 65 0 1) for ctrl+a (keyValue 1/charCode 65) > but > #(2 7329656 1 0 2 1 0 1) for ctrl+home (keyValue 1/charCode 1) > > this may need some changes on the image side. For example, in Pharo we > have some special handling that adds "96" to the keyValue for keystrokes > with ctrl-key). > > What do you think? > > > > nicolai >
