Squeak-dev December 2015

squeak-dev@lists.squeakfoundation.org

60 participants
161 discussions

Re: [squeak-dev] Recovering method changes after crash
by Jakob Reschke 11 Dec '15

11 Dec '15

Hi Ralph, I think what you are looking for is "Extras > Recover Changes" in the world main docking bar. But the path you mentioned with "World Menu > changes > recently logged changes" does exist as well in my 4.6 images, so I wonder why it was not there for you. Best regards, Jakob 2015-12-11 21:00 GMT+01:00 Ralph Boland <rpboland(a)gmail.com>: > I recently upgraded from Squeak 3.11 to Squeak 4.6 > Overall it seems better and particular much faster. > However, I do have a problem. > In Squeak 3.11 whenever my image crashed for any reason > (The most common was I got into an infinite loop I couldn't kill > from within Squeak and had to do so from the Linux command line.) > I could recover the changes not in the must recent save of my image > by restarting squeak on that image and then > opening changes>>recently logged changes and selecting the methods > I wanted reloaded into my image and then reloading them. > > But in Squeak 4.6 there seems to be no way to do this. > In Squeak 4.6, after a crash of the image, how do I recover the > (possibly many) methods/changes > in the changes file but not in the image? > If there is no easy way to do this in 4.6 then this is a major > disadvantage over 3.11 to my mind. > I assume I am actually missing something simple here so apologies for > being slow here. > > Sincerely, > > Ralph Boland >

1 0

Re: [Pharo-dev] Unicode Support
by EuanM 11 Dec '15

11 Dec '15

I agree with all of that, Ben. I'm currently fairly certain that fully-composed abstract characters is a term that is 1:1 mapped with the term "grapheme cluster" (i.e. one is an older Unicode description of a newer Unicode term). And once we create these, I think this sort of implementation is straightforward. For particular values of "straightforward", of course :-) i.e. the Swift approach is equivalent to the approach I originally proposed and asked for critiques of. One thing I don't understand.... why does the fact the composed abstract character (aka grapheme cluster) is a sequence mean that an array cannot be used to hold the sequence? If people then also want a compatibility-codepoints-only UTF-8 representation, it is simple to provide comparable (i.e equivalence-testable) versions of any UTF-8 string - because we are creating them from composed forms by a *single* defined method. For my part, the reason I think we ought to implement it *in* Smalltalk is ... this is the String class of the new age. I want Smalltalk to be handle Strings as native objects. On 10 December 2015 at 23:41, Ben Coman <btc(a)openinworld.com> wrote: > On Wed, Dec 9, 2015 at 5:35 PM, Guillermo Polito > <guillermopolito(a)gmail.com> wrote: >> >>> On 8 dic 2015, at 10:07 p.m., EuanM <euanmee(a)gmail.com> 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 seems to be what Swift is doing, where Strings are not composed > not of codepoints but of graphemes. > >>>> "Every instance of Swift’s Character type represents a single extended grapheme cluster. An extended grapheme cluster is a sequence** of one or more Unicode scalars that (when combined) produce a single human-readable character. [1] > > ** i.e. not an array > >>>> Here’s an example. The letter é can be represented as the single Unicode scalar é (LATIN SMALL LETTER E WITH ACUTE, or U+00E9). However, the same letter can also be represented as a pair of scalars—a standard letter e (LATIN SMALL LETTER E, or U+0065), followed by the COMBINING ACUTE ACCENT scalar (U+0301). TheCOMBINING ACUTE ACCENT scalar is graphically applied to the scalar that precedes it, turning an e into an éwhen it is rendered by a Unicode-aware text-rendering system. [1] > >>>> In both cases, the letter é is represented as a single Swift Character value that represents an extended grapheme cluster. In the first case, the cluster contains a single scalar; in the second case, it is a cluster of two scalars:" [1] > >>>> Swiftʼs string implemenation makes working with Unicode easier and significantly less error-prone. As a programmer, you still have to be aware of possible edge cases, but this probably cannot be avoided completely considering the characteristics of Unicode. [2] > > Indeed I've tried searched for what problems it causes and get a null > result. So I read *all*good* things about Swift's unicode > implementation reducing common errors dealing with Unicode. Can > anyone point to complaints about Swift's unicode implementation? > Maybe this... > >>>> An argument could be made that the implementation of String as a sequence that requires iterating over characters from the beginning of the string for many operations poses a significant performance problem but I do not think so. My guess is that Appleʼs engineers have considered the implications of their implementation and apps that do not deal with enormous amounts of text will be fine. Moreover, the idea that you could get away with an implementation that supports random access of characters is an illusion given the complexity of Unicode. [2] > > Considering our common pattern: Make it work, Make it right, Make it > fast -- maybe Strings as arrays are a premature optimisation, that > was the right choice in the past prior to Unicode, but considering > Moore's Law versus programmer time, is not the best choice now. > Should we at least start with a UnicodeString and UnicodeCharacter > that operates like Swift, and over time *maybe* move the tools to use > them. > > [1] https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swif… > [2] http://oleb.net/blog/2014/07/swift-strings/ > > cheers -ben > >> >>> >>> 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 >

4 5

Re: [Pharo-dev] Unicode Support
by EuanM 11 Dec '15

11 Dec '15

"If it hasn't already been said, please do not conflate Unicode and UTF-8. I think that would be a recipe for a high P.I.T.A. factor." --Richard Sargent I agree. :-) Regarding UTF-16, I just want to be able to export to, and receive from, Windows (and any other platforms using UTF-16 as their native character representation). Windows will always be able to accept UTF-16. All Windows apps *might well* export UTF-16. There may be other platforms which use UTF-16 as their native format. I'd just like to be able to cope with those situations. Nothing more. All this is requires is a Utf16String class that has an asUtf8String method (and any other required conversion methods). And other string classes to have asUtf16String classes. Once we have the other classes and methods, this should be a trivial extensions. Export will just be transformations of existing formats of valid strings. Import just needs to transform to (one of) our preferred format(s), and have a validity check performed after the transform is complete. On 11 December 2015 at 15:37, Richard Sargent <richard.sargent(a)gemtalksystems.com> wrote: > EuanM wrote >> ... >> all ISO-8859-1 maps 1:1 to Unicode UTF-8 >> ... > > I am late coming in to this conversation. If it hasn't already been said, > please do not conflate Unicode and UTF-8. I think that would be a recipe for > a high P.I.T.A. factor. > > Unicode defines the meaning of the code points. > UTF-8 (and -16) define an interchange mechanism. > > In other words, when you write the code points to an external medium > (socket, file, whatever), encode them via UTF-whatever. Read UTF-whatever > from an external medium and re-instantiate the code points. > (Personally, I see no use for UTF-16 as an interchange mechanism. Others may > have justification for it. I don't.) > > Having characters be a consistent size in their object representation makes > everything easier. #at:, #indexOf:, #includes: ... no one wants to be > scanning through bytes representing variable sized characters. > > Model Unicode strings using classes such as e.g. Unicode7, Unicode16, and > Unicode32, with automatic coercion to the larger character width. > > > > > -- > View this message in context: http://forum.world.st/Unicode-Support-tp4865139p4866610.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

1 0

Recovering method changes after crash
by Ralph Boland 11 Dec '15

11 Dec '15

I recently upgraded from Squeak 3.11 to Squeak 4.6 Overall it seems better and particular much faster. However, I do have a problem. In Squeak 3.11 whenever my image crashed for any reason (The most common was I got into an infinite loop I couldn't kill from within Squeak and had to do so from the Linux command line.) I could recover the changes not in the must recent save of my image by restarting squeak on that image and then opening changes>>recently logged changes and selecting the methods I wanted reloaded into my image and then reloading them. But in Squeak 4.6 there seems to be no way to do this. In Squeak 4.6, after a crash of the image, how do I recover the (possibly many) methods/changes in the changes file but not in the image? If there is no easy way to do this in 4.6 then this is a major disadvantage over 3.11 to my mind. I assume I am actually missing something simple here so apologies for being slow here. Sincerely, Ralph Boland

1 0

Daily Commit Log
by commits＠source.squeak.org 10 Dec '15

10 Dec '15

Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours: http://lists.squeakfoundation.org/pipermail/packages/2015-December/009214.h… Name: Morphic-mt.1059 Ancestors: Morphic-tpr.1058 Fixes bug regarding the scaling of 8-bit color forms. =============================================

1 0

Re: [squeak-dev] The Inbox: Tools-pre.659.mcz
by karl ramberg 10 Dec '15

10 Dec '15

Nice. Best, Karl On Tue, Dec 8, 2015 at 7:16 PM, <commits(a)source.squeak.org> wrote: > A new version of Tools was added to project The Inbox: > http://source.squeak.org/inbox/Tools-pre.659.mcz > > ==================== Summary ==================== > > Name: Tools-pre.659 > Author: pre > Time: 8 December 2015, 7:16:41.034 pm > UUID: a7cb3cba-074b-46a6-8a83-fada58007b25 > Ancestors: Tools-eem.658 > > This adds balloon help texts to the message list of the standard browser > to explain the symbols shown in front of message names. > > =============== Diff against Tools-eem.658 =============== > > Item was changed: > ----- Method: Browser>>messageHelpAt: (in category 'message list') ----- > messageHelpAt: anIndex > "Show the first n lines of the sources code of the selected > message." > > + | source formatted | > - | source formatted lineCount | > Preferences balloonHelpInMessageLists ifFalse: [^ nil]. > self messageList size < anIndex ifTrue: [^ nil]. > > source := (self selectedClassOrMetaClass >> (self messageList at: > anIndex)) getSource. > + source lineCount > 5 ifTrue: [ > + | sourceLines | > + sourceLines := (source asString lines copyFrom: 1 to: 5) > asOrderedCollection. > + sourceLines add: ' [...]'. > + source := sourceLines joinSeparatedBy: Character cr]. > + > formatted := SHTextStylerST80 new > classOrMetaClass: self selectedClassOrMetaClass; > styledTextFor: source asText. > - > - lineCount := 0. > - source doWithIndex: [:char :index | > - char = Character cr ifTrue: [lineCount := lineCount + 1]. > - lineCount > 10 ifTrue: [ > - formatted := formatted copyFrom: 1 to: index-1. > - formatted append: ' [...]'. > - ^ formatted]]. > > + ^ (Text newFrom: ((self messageIconHelpAt: anIndex) ifNotEmpty: > [:t | t , Character cr, Character cr])) > + append: formatted; > + yourself! > - ^ formatted! > > Item was added: > + ----- Method: Browser>>messageIconHelpAt: (in category 'message list') > ----- > + messageIconHelpAt: anIndex > + > + self class showMessageIcons > + ifFalse: [^ nil]. > + > + ^ ToolIconHelp iconHelpNamed: (ToolIcons > + iconForClass: self selectedClassOrMetaClass > + selector: (self messageList at: anIndex))! > > Item was added: > + Object subclass: #ToolIconHelp > + instanceVariableNames: '' > + classVariableNames: 'HelpTexts' > + poolDictionaries: '' > + category: 'Tools-Base'! > > Item was added: > + ----- Method: ToolIconHelp class>>abstract (in category 'as yet > unclassified') ----- > + abstract > + > + ^ 'This method is abstract.' ! > > Item was added: > + ----- Method: ToolIconHelp class>>arrowDown (in category 'as yet > unclassified') ----- > + arrowDown > + > + ^ 'This method is overriden by another method.'! > > Item was added: > + ----- Method: ToolIconHelp class>>arrowUp (in category 'as yet > unclassified') ----- > + arrowUp > + > + ^ 'This method overrides a super method.'! > > Item was added: > + ----- Method: ToolIconHelp class>>arrowUpAndDown (in category 'as yet > unclassified') ----- > + arrowUpAndDown > + > + ^ 'This method overrides and is overridden by other methods.'! > > Item was added: > + ----- Method: ToolIconHelp class>>blank (in category 'as yet > unclassified') ----- > + blank > + > + ^ ''! > > Item was added: > + ----- Method: ToolIconHelp class>>breakpoint (in category 'as yet > unclassified') ----- > + breakpoint > + > + ^ 'This method contains a breakpoint.'! > > Item was added: > + ----- Method: ToolIconHelp class>>flag (in category 'as yet > unclassified') ----- > + flag > + > + ^ 'This method needs attention of some kind.' ! > > Item was added: > + ----- Method: ToolIconHelp class>>helpTexts (in category 'as yet > unclassified') ----- > + helpTexts > + > + ^ HelpTexts ifNil: [HelpTexts := IdentityDictionary new]! > > Item was added: > + ----- Method: ToolIconHelp class>>iconHelpNamed: (in category 'as yet > unclassified') ----- > + iconHelpNamed: aSymbol > + > + (self respondsTo: aSymbol) > + ifTrue: [^self helpTexts at: aSymbol ifAbsentPut: [self > perform: aSymbol]] > + ifFalse: [^ ''] > + ! > > Item was added: > + ----- Method: ToolIconHelp class>>no (in category 'as yet unclassified') > ----- > + no > + > + ^ 'This method should not be implemented.' ! > > Item was added: > + ----- Method: ToolIconHelp class>>notOverridden (in category 'as yet > unclassified') ----- > + notOverridden > + > + ^ 'This method is abstract and has not been overridden.' ! > > Item was added: > + ----- Method: ToolIconHelp class>>primitive (in category 'as yet > unclassified') ----- > + primitive > + > + ^ 'This method implements a primitive.'! > > >

6 14

Explorer bug when inspecting a ColorForm
by tim Rowledge 10 Dec '15

10 Dec '15

(In a 15566 update image) If you try to ‘explore’ a morph that returns a ColorForm for #iconOrThumbnail we have a oroblem because Form>scaledIntoFormOfSize:smoothing: makes the assumption that 32bpp is appropriate - which isn’t true for ColorForms, as you can see if you look at ColorForm>setExtent:depth: I guess it’s the use of ‘self species’ that is the real problem. Latest version is from this august, by marcel, so maybe you have a simple solution? Im in the midst of more complication than I can describe, so I’m not about to fix this right now... tim -- tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Illiud Latine dici non potest = You can't say that in Latin.

3 5

The Trunk: Morphic-mt.1059.mcz
by commits＠source.squeak.org 10 Dec '15

10 Dec '15

Marcel Taeumel uploaded a new version of Morphic to project The Trunk: http://source.squeak.org/trunk/Morphic-mt.1059.mcz ==================== Summary ==================== Name: Morphic-mt.1059 Author: mt Time: 10 December 2015, 9:49:58.039 am UUID: cbaef52e-fd80-4151-9a73-53b4eededc97 Ancestors: Morphic-tpr.1058 Fixes bug regarding the scaling of 8-bit color forms. =============== Diff against Morphic-tpr.1058 =============== Item was changed: ----- Method: Form>>scaledIntoFormOfSize:smoothing: (in category '*Morphic') ----- scaledIntoFormOfSize: aNumberOrPoint smoothing: factor "Scale and center the receiver into a form of a given size" | extent scaledForm result | extent := aNumberOrPoint asPoint. extent = self extent ifTrue: [^ self copy]. scaledForm := self scaledToSize: extent smoothing: factor. + result := self species extent: extent depth: self depth. - result := self species extent: extent depth: 32. result getCanvas translucentImage: scaledForm at: extent - scaledForm extent // 2. ^ result !

1 0

Daily Commit Log
by commits＠source.squeak.org 09 Dec '15

09 Dec '15

Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours: http://lists.squeakfoundation.org/pipermail/packages/2015-December/009212.h… Name: Morphic-tpr.1058 Ancestors: Morphic-cwp.1057, Morphic-tpr.1057 Transfer from inbox, keep up to date. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2015-December/009213.h… Name: Tools-pre.659 Ancestors: Tools-eem.658 This adds balloon help texts to the message list of the standard browser to explain the symbols shown in front of message names. =============================================

1 0

Call for Papers: Reflect'16, Workshop on Reflection and Runtime Meta-Programming Techniques
by Stefan Marr 09 Dec '15

09 Dec '15

Call for Papers: Reflect’16 =========================== Workshop on Reflection and Runtime Meta-Programming Techniques Co-located with Modularity 2016 March 14 or 15, 2016, Málaga, Spain Twitter @ReflectWorkshop http://2016.modularity.info/track/Reflect-2016-papers With modern mainstream languages embracing runtime reflection, for instance in JavaScript with proxies and Ruby with its culture of using meta-programming, the research on meta-architectures, reflective programming, and other meta-programming techniques have become relevant and timely once again. Over the last couple of years, these techniques saw a surge of interest benefiting from the JavaScript standardization process as well as performance improvements based on just-in-time compilation that increased their general acceptance. The Reflect’16 workshop aims to bring together people who do research on reflection and runtime meta-programming, as well as users of such techniques to e.g. build applications, language extensions, or software tools. We invite contributions to the workshop on a wide range of topics related to design, implementation, and application of reflective APIs and runtime meta-programming techniques, as well as empirical studies and typing for such systems and languages. We welcome technical papers as well as work-in-progress and position papers from the academic as well as industrial perspective. Position paper should take a perhaps controversial stance on a specific topic and argue the position well. Topics of Interest ------------------ The topics of interest for the workshop include, but are not limited to: - applications to middleware, frameworks, and DSLs - reflection and metaobject protocols to enable tooling - meta-level architectures and reflective middleware for modern runtime platforms (e.g. IoT, cyber-physical systems, cloud/grid computing, exa-scale systems, smart grids, mobile systems) - optimization techniques to minimize runtime overhead of reflection - use for application-level runtime optimization - new language constructs for reflection and meta-programming - security in reflective systems and capability-based designs - application of reflective techniques to achieve adaptability, separation of concerns, code reuse, etc. - empirical studies to the dynamic behavior of reflective programs - application to enable complex concurrent systems - typing of reflective programs Workshop Format and Submissions ------------------------------- This workshop welcomes the presentation of mature work as well as discussion of new ideas and emerging problems as part of a mini-conference format. Furthermore, we plan for more interactive brainstorming and demonstration sessions between the formal presentations to enable an active exchange of ideas. The workshop papers will be published in both the electronic proceedings of the Modularity conference and in the ACM Digital Library, if not requested otherwise by the authors. Papers are to be submitted using the ACM sigplanconf style at 9pt font size. See http://www.acm.org/publications/article-templates/proceedings-template.html. position and work-in-progress paper: max. 4 pages technical paper: max. 8 pages demos and posters: 1-page abstract For the submission, please use the EasyChair system: https://easychair.org/conferences/?conf=reflect16 Important Dates --------------- abstract submission: January 11, 2016 paper submission: January 15, 2016 notification: February 6, 2016 camera-ready: February 13, 2016 all deadlines: Anywhere on Earth (AoE), i.e., GMT/UTC−12:00 hour Workshop Organizers ------------------- Gilad Bracha, Google Shigeru Chiba, University of Tokyo Elisa Gonzalez Boix, Vrije Universiteit Brussel Stefan Marr, Johannes Kepler University Linz Program Committee ----------------- Daniele Bonetta, Oracle Labs, Austria Damien Cassou, University of Lille 1, France Siobhan Clarke, Trinity College Dublin, Ireland Stephane Ducasse, Inria, France Robert Hirschfeld, HPI, Germany Hridesh Rajan, Iowa State University, USA Romain Rouvoy, University Lille 1 and INRIA, France Eric Tanter, University of Chile, Chile Laurie Tratt, King’s College, UK Tom Van Cutsem, Bell Labs, Belgium Takuo Wantanabe, Tokyo Institute of Technology, Japan Tijs van der Storm, CWI, NL -- Stefan Marr Johannes Kepler Universität Linz http://stefan-marr.de/research/

1 0

← Newer
1
...
7
8
9
10
11
12
13
...
17
Older →

Jump to page: