Re: [Pharo-project] [Ann] TxText. New text editor done!
2013/4/28 stephane ducasse > Hi denis > > Alain is gone on vacation but it told me that if you code scale he will > throw away what he did :) > May be the decorators that alain wrote can be merged. > In any case this is excellent to get a better system. > Yes. This is why I work on this project. But my first proposals was not make editor for large text. I actually not think about it at all. My main idea is make clean and extendible text editor. So anybody can understand how layout built, where text insertion happens, how it processed, how cursor wors and etc. I want text editor which is not required hacks to simple tasks like allow only numbers, hide cursor, disable text selection, make masked input, make smart completions and etc. > Stef > > > On Apr 27, 2013, at 5:17 PM, Denis Kudriashov > wrote: > > > I should say it is not difficult to do with current design. I were > > think about it and current layout building logic requires little > > changes, maybe just one spesific method. > > > > But there is cases where any text change required rebuilding full > > layout. Fo example, single line text with wrapping mode. > > > > > > 2013/4/27, Igor Stasenko : > >> Very impressive progress, Denis! :) > >> > >> I going to finish low-level stuff in Athens (path approximation / > >> point location) > >> and then go straight to text rendering with existing Text. > >> Next stage will be to take TxText model and provide rendering for it > >> with Athens, > >> as well as review the code. > >> > >> About text editing and re-layout. > >> It should be possible that any local update (which affecting only > >> single character span or multiple adjusted character spans will > >> require only local recalculations of text layout). Otherwise there is > >> no reason why in our model we don't keep whole text in single big > >> buffer (like Text does). > >> Splitting text on multiple spans was the reason to make local layout > >> updates possible. > >> But i know it is not that easy to do :) > >> > >> > >> -- > >> Best regards, > >> Igor Stasenko. > >> > >> > > > > >
Re: [Pharo-project] Trying to understand DateAndTime
thanks a lot!
Friday we have an official sprint so I'm sure that this issue will be
addressed.
Stef
> See https://pharo.fogbugz.com/default.asp?10425# and corresponding SLICE in
> 3.0 inbox
> Note: I don't know what is the policy with the labels/states of these bug
> tracker, and it rather bothers me, but the SLICE is ready for tests/reviews.
>
>
> 2013/4/27 Nicolas Cellier
> There is more:
>
> 1) hasEqualTicks: use julianDayNumber instead of julianDayNumberUTC
> 2) (Time dateAndTime now) interprets the (Time localSeconds) which are from
> the wrong primitive (seconds ellapsed since squeak epoch translated to local
> time) as seconds ellapsed since squeak Epoch (UTC time).
>
> We should really ban the old primitive 137 and only use the new one (240
> which works with UTC microseconds).
>
> I think Camillo did a good job, but he stopped cleaning too soon.
> Ah, young guys are so impatient to invent the future ;)
>
>
> 2013/4/27 stephane ducasse
>
> On Apr 27, 2013, at 6:33 PM, Nicolas Cellier
> wrote:
>
> > Since DateAndTime comment is out of date (sic !) and current implementation
> > seems not free of bug, here is an effort to summarize and understand the
> > whole thing, let's call this a review.
>
> Thanks this is a great initiative!
>
>
> > Please tell me where my interpretations are wrong.
> >
> > 1) The DateAndTime is stored internally as
> > - a point in UTC time (julianDayNumber, seconds, nanos)
> > - an offset from UTC (a Duration) denoting the local time zone
> >
> > 2) The ticks method returns the UTC part {julianDayNumber. seconds. nanos}
> >
> > 3) DateAndTime print themselves in local time using the offset
> >
> > 4) other methods (with some exceptions) return the local dateAndTime parts
> > (year month day hours minutes seconds)
> >
> > Exceptions are:
> > - secondsSinceMidnight (which should be renamed secondsSinceMidnightUTC
> > IMO, even if the method is classified private)
> > - julianDayNumberUTC as the name tells
> >
> > So far so good (but secondsSinceMidnight which is error prone)
> >
> > What I find strange:
> > - #hash uses the offset... Why ???
> >
> > d1 := DateAndTime now.
> > d2 := d1 offset: d1 offset + 1 hours.
> > {
> > d1 = d2.
> > d1 hash = d2 hash.
> > }
> > gives #(true false), a clue?
> >
> > - #< compares julianDayNumber (the UTC inst. var.) with otherDate
> > julianDayNumber (with otherDate local offset) which seems wrong, it should
> > better use julianDayNumberUTC or (normalized) ticks.
> >
> > - #= could be simplified and accelerated if using #hasEqualTicks: (if the
> > ticks are correctly normalized though which would be the case since
> > #ticks:offset: does, unfortunately #setJdn:seconds:nanos:offset: does not).
> >
> > Some senders of #setJdn:seconds:nanos:offset: don't normalize the
> > day/seconds/nanos, though it should be their responsibility (DateAndTime
> > todayAtMilliSeconds: xxx) (DateAndTime todayAtNanoSeconds: xxx), not
> > counting year:month:day:hour:minute:second:nanoSecond:offset: which does
> > not either (many senders...).
> > Maybe we should better let the normalization responsibility to
> > #setJdn:seconds:nanos:offset:.
> >
> > It remain to analyze the conversion protocol (asYear etc...) which seems to
> > use the local time year, but I don't understand the whole Timespan thing
> > right now (why DateAndTime now asYear starts now, and not on january 1st?).
> >
> > Nicolas
> >
> >
>
>
>
>
Re: [Pharo-project] [Ann] TxText. New text editor done!
Hi 2013/4/27 Sean P. DeNigris > Sean P. DeNigris wrote > > You're my new best friend :) > > The cursor is an actual Morph (TxCursorMorph) instead of magic conjured up > my Paragraph!!! All my other friends are fired, they've never given me a > present this nice :) > :) > > Also, please add me to the repo. I have a small fix (TxCursorMorph should > show cursorColor instead of defaultColor) > > I not have permissions for that. Igor can you add Sean as contributor? I were make another fixes and I added your find too. > > > - > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Ann-TxText-New-text-editor-done-tp4683876p4683990.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >
Re: [Pharo-project] Trying to understand DateAndTime
Nicolas Cellier wrote > Note: I don't know what is the policy with the labels/states of these bug > tracker, and it rather bothers me, but the SLICE is ready for > tests/reviews. I was a bit confused at first too. You have to click "Resolved" and then you get a whole other set of states, including "fix review needed". I've done it for this issue... - Cheers, Sean -- View this message in context: http://forum.world.st/Trying-to-understand-DateAndTime-tp4683997p4684063.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] Trying to understand DateAndTime
See https://pharo.fogbugz.com/default.asp?10425# and corresponding SLICE in
3.0 inbox
Note: I don't know what is the policy with the labels/states of these bug
tracker, and it rather bothers me, but the SLICE is ready for tests/reviews.
2013/4/27 Nicolas Cellier
> There is more:
>
> 1) hasEqualTicks: use julianDayNumber instead of julianDayNumberUTC
> 2) (Time dateAndTime now) interprets the (Time localSeconds) which are
> from the wrong primitive (seconds ellapsed since squeak epoch translated to
> local time) as seconds ellapsed since squeak Epoch (UTC time).
>
> We should really ban the old primitive 137 and only use the new one (240
> which works with UTC microseconds).
>
> I think Camillo did a good job, but he stopped cleaning too soon.
> Ah, young guys are so impatient to invent the future ;)
>
>
> 2013/4/27 stephane ducasse
>
>>
>> On Apr 27, 2013, at 6:33 PM, Nicolas Cellier <
>> nicolas.cellier.aka.n...@gmail.com> wrote:
>>
>> > Since DateAndTime comment is out of date (sic !) and current
>> implementation seems not free of bug, here is an effort to summarize and
>> understand the whole thing, let's call this a review.
>>
>> Thanks this is a great initiative!
>>
>>
>> > Please tell me where my interpretations are wrong.
>> >
>> > 1) The DateAndTime is stored internally as
>> > - a point in UTC time (julianDayNumber, seconds, nanos)
>> > - an offset from UTC (a Duration) denoting the local time zone
>> >
>> > 2) The ticks method returns the UTC part {julianDayNumber. seconds.
>> nanos}
>> >
>> > 3) DateAndTime print themselves in local time using the offset
>> >
>> > 4) other methods (with some exceptions) return the local dateAndTime
>> parts (year month day hours minutes seconds)
>> >
>> > Exceptions are:
>> > - secondsSinceMidnight (which should be renamed secondsSinceMidnightUTC
>> IMO, even if the method is classified private)
>> > - julianDayNumberUTC as the name tells
>> >
>> > So far so good (but secondsSinceMidnight which is error prone)
>> >
>> > What I find strange:
>> > - #hash uses the offset... Why ???
>> >
>> > d1 := DateAndTime now.
>> > d2 := d1 offset: d1 offset + 1 hours.
>> > {
>> > d1 = d2.
>> > d1 hash = d2 hash.
>> > }
>> > gives #(true false), a clue?
>> >
>> > - #< compares julianDayNumber (the UTC inst. var.) with otherDate
>> julianDayNumber (with otherDate local offset) which seems wrong, it should
>> better use julianDayNumberUTC or (normalized) ticks.
>> >
>> > - #= could be simplified and accelerated if using #hasEqualTicks: (if
>> the ticks are correctly normalized though which would be the case since
>> #ticks:offset: does, unfortunately #setJdn:seconds:nanos:offset: does not).
>> >
>> > Some senders of #setJdn:seconds:nanos:offset: don't normalize the
>> day/seconds/nanos, though it should be their responsibility (DateAndTime
>> todayAtMilliSeconds: xxx) (DateAndTime todayAtNanoSeconds: xxx), not
>> counting year:month:day:hour:minute:second:nanoSecond:offset: which does
>> not either (many senders...).
>> > Maybe we should better let the normalization responsibility to
>> #setJdn:seconds:nanos:offset:.
>> >
>> > It remain to analyze the conversion protocol (asYear etc...) which
>> seems to use the local time year, but I don't understand the whole Timespan
>> thing right now (why DateAndTime now asYear starts now, and not on january
>> 1st?).
>> >
>> > Nicolas
>> >
>> >
>>
>>
>>
>
Re: [Pharo-project] Pharo 3.0 TestRunner results
Here are the results with Pharo 3.0, update 30068). See attached file. I'm on Windows XP SP3. - Benoit St-Jean Yahoo! Messenger: bstjean Blogue: endormitoire.wordpress.com A standpoint is an intellectual horizon of radius zero. (Albert Einstein) 10531 run, 10496 passes, 2 skipped, 30 expected failures, 5 failures, 0 errors, 0 unexpected passes Failures: ClassDescriptionTest>>#testUnCategorizedMethods SimulateMouseSpecification>>#testSimulateClick ReleaseTest>>#testSystemAnnouncerIsUnique DateTest>>#testNew TimeStampTest>>#testMinusSecondsOverMidnight Errors:
Re: [Pharo-project] Trying to understand DateAndTime
There is more:
1) hasEqualTicks: use julianDayNumber instead of julianDayNumberUTC
2) (Time dateAndTime now) interprets the (Time localSeconds) which are from
the wrong primitive (seconds ellapsed since squeak epoch translated to
local time) as seconds ellapsed since squeak Epoch (UTC time).
We should really ban the old primitive 137 and only use the new one (240
which works with UTC microseconds).
I think Camillo did a good job, but he stopped cleaning too soon.
Ah, young guys are so impatient to invent the future ;)
2013/4/27 stephane ducasse
>
> On Apr 27, 2013, at 6:33 PM, Nicolas Cellier <
> nicolas.cellier.aka.n...@gmail.com> wrote:
>
> > Since DateAndTime comment is out of date (sic !) and current
> implementation seems not free of bug, here is an effort to summarize and
> understand the whole thing, let's call this a review.
>
> Thanks this is a great initiative!
>
>
> > Please tell me where my interpretations are wrong.
> >
> > 1) The DateAndTime is stored internally as
> > - a point in UTC time (julianDayNumber, seconds, nanos)
> > - an offset from UTC (a Duration) denoting the local time zone
> >
> > 2) The ticks method returns the UTC part {julianDayNumber. seconds.
> nanos}
> >
> > 3) DateAndTime print themselves in local time using the offset
> >
> > 4) other methods (with some exceptions) return the local dateAndTime
> parts (year month day hours minutes seconds)
> >
> > Exceptions are:
> > - secondsSinceMidnight (which should be renamed secondsSinceMidnightUTC
> IMO, even if the method is classified private)
> > - julianDayNumberUTC as the name tells
> >
> > So far so good (but secondsSinceMidnight which is error prone)
> >
> > What I find strange:
> > - #hash uses the offset... Why ???
> >
> > d1 := DateAndTime now.
> > d2 := d1 offset: d1 offset + 1 hours.
> > {
> > d1 = d2.
> > d1 hash = d2 hash.
> > }
> > gives #(true false), a clue?
> >
> > - #< compares julianDayNumber (the UTC inst. var.) with otherDate
> julianDayNumber (with otherDate local offset) which seems wrong, it should
> better use julianDayNumberUTC or (normalized) ticks.
> >
> > - #= could be simplified and accelerated if using #hasEqualTicks: (if
> the ticks are correctly normalized though which would be the case since
> #ticks:offset: does, unfortunately #setJdn:seconds:nanos:offset: does not).
> >
> > Some senders of #setJdn:seconds:nanos:offset: don't normalize the
> day/seconds/nanos, though it should be their responsibility (DateAndTime
> todayAtMilliSeconds: xxx) (DateAndTime todayAtNanoSeconds: xxx), not
> counting year:month:day:hour:minute:second:nanoSecond:offset: which does
> not either (many senders...).
> > Maybe we should better let the normalization responsibility to
> #setJdn:seconds:nanos:offset:.
> >
> > It remain to analyze the conversion protocol (asYear etc...) which seems
> to use the local time year, but I don't understand the whole Timespan thing
> right now (why DateAndTime now asYear starts now, and not on january 1st?).
> >
> > Nicolas
> >
> >
>
>
>
Re: [Pharo-project] Opal Decompiler status
On Apr 27, 2013, at 8:00 PM, Nicolas Cellier wrote: > Right, if you embed source along with CompiledMethod (to handle the case when > the CompiledMethod has been replaced but one of its block of code is still > used), then you don't need Decompiler in the first place. > > Nonetheless, I would remove the .sources but not the .changes. The .changes > is not only a source code repository (that feature can go away if you want), > it's before all a change log, an insurance to retrieve some change when > everything else failed (image crashed or worse corrupted image won't > restart). You can make the insurance optional if you want, but please > continue to provide an equivalent service. A change file is the most simple > thing that could possibly work IMO. But this is another thread. I agree, we have been discussing (and I do not like much the idea to have the changes inside the image as objects because now we have a nice literal object parser/writer and making sure that we can never lose source code is cool). In any case we are working on a new change format recording more high-level entity (such refactoring). We looked again at the model that veronica did, and Ezequiel and we looked again at DeltaStreams. We should digest all that and come up with a new alternate changes model file. I was about to contact goran to see if he wants to participate/ read a paper but we should write the paper first :) > Concerning the temp mapping, I agree, we should not compete with Eliot, he's > very tough at tedious tasks, our only weapon is lazyness, lazyness often > leads to efficiency ;) I'm curious to check how you handled this complex part > with AST when I'll have more time to dig. > > > 2013/4/27 Marcus Denker > > On Apr 27, 2013, at 6:42 PM, Nicolas Cellier > wrote: > > > Thanks Marcus. > > I'm among the skepticals concerning the AST, but I'd like to be proven > > wrong, because AST level would certainly simplify things a lot. > > My main reserve is that interruption can occur at BC level, so for > > debugging purpose, what are your plans? > > Will you move the PC at some AST node boundary (if it is possible given > > side effects of some BC)? > > > For the Debugger, everything stays as it is (until Pharo 4 or so)… if you > look at it, the current Debugger never decompiles if there is source > available. > It *compiles* to get > -> the mapping BC -> text > -> the information how temporary variables in the byte code are > actually related to temps in the source. > (this is very complex, temps can be e.g. stored on the heap if > they are written to in a closure, and when they are just > read they have a different offset in each closure they are in. > Conversely, some temps in the byte code are used > to store the array that hold the variables that are on the heap…) > > The old compiler recorded mappings while compiling that where encoded… quite > complex, at least for my tiny brain. > > So the new just keeps the AST annotated with all the needed infos, this is > much easier to debug (and we do have the > memory these days, and as we cache the AST, it's even fast). > > So the debugger needs the compiler. The decompiler now exists just to make > text so that we can call the compiler > in the case there is no .sources. The debugger *always* compiles to get the > mappings, as soon as there is source code > the decompiler will never be used. (and even if the decompiler is used, the > compiler is called right after on it's results so > one can record the mappings). > > So if you make sure there is always source-code (or a representation with the > right amount of meta data), you don't need the decompiler. > > So at the start it will be the source code. And yes, this takes memory. But > we are in 2013 and if we have one thing than it's memory. > (the $25 Raspi comes with 256MB, the $35 with 512MB…). > > We could have shipped 2.0 with 8MB of useless Monticello meta data and nobody > would have even realized it. (like we > have now megabytes of fonts in the image…). Yet the source is special… I > really wonder why. > > (And yes, there should be solutions to not need unused data in main memory > and solutions to share across multiple images > data that is the same… but for all kinds of stuff, not just source code). > > Marcus >
Re: [Pharo-project] Opal Decompiler status
> Thanks Marcus. > I'm among the skepticals concerning the AST, but I'd like to be proven wrong, > because AST level would certainly simplify things a lot. Me too :) But marcus knows it since the end of his PhD :D. This is why I really want to see AST compression. > My main reserve is that interruption can occur at BC level, so for debugging > purpose, what are your plans? > Will you move the PC at some AST node boundary (if it is possible given side > effects of some BC)? > > > 2013/4/27 Marcus Denker > > On Apr 27, 2013, at 5:59 PM, Marcus Denker wrote:. > > > >> Could we have a primer on what remains to do on the Opal front? > >> > > > > > > -> debug BC-IR->AST->text mapping more (lots of it working already) > > -> debug temp variable lookup in optimized blocks in the debugger (almost > > there, too) > > -> Go through all the test for the old Compiler and port them to the new. > > -> Better compiler API and refactor the whole system to use it > > (but keep a backward compatible API at least to some extend) > > > All the TODOs are in the bug tracker, Project "Compiler (Opal)". > > There are right now 29 Issues. > > Marcus >
Re: [Pharo-project] Opal Decompiler status
But I would like that we finish first all the other cool tasks for 3.0 before opening something new. Finishing is difficult so let us focus on it. Stef On Apr 27, 2013, at 8:13 PM, Marcus Denker wrote: > > On Apr 27, 2013, at 8:01 PM, Nicolas Cellier > wrote: > >> Right, if you embed source along with CompiledMethod (to handle the case >> when the CompiledMethod has been replaced but one of its block of code is >> still used), then you don't need Decompiler in the first place. >> >> Nonetheless, I would remove the .sources but not the .changes. The .changes >> is not only a source code repository (that feature can go away if you want), >> it's before all a change log, an insurance to retrieve some change when >> everything else failed (image crashed or worse corrupted image won't >> restart). You can make the insurance optional if you want, but please >> continue to provide an equivalent service. A change file is the most simple >> thing that could possibly work IMO. But this is another thread. >> > Yes, we have a solution for that… > > the thing is that the .changes has 3 roles. In the 1978, it was very clever > to design one extremely memory efficient mechanism to kill all three: > > 1) keep a history of all the accepted method sources in the image (see > "versions") > 2) store the code on disk efficiently with no duplications (They counted > those extremely expensive disks in the one-diget Megabytes back then). > 3) have transaction log for the source code in case of image crash. > > Now today, we can solve all three using three different methods: > > 1) we will just keep the accepted methods in memory until you commit to > monticello/git > (in case of git one can even commit all the intermediates, for MC one > would just commit the latest). >after the in-image history is pruned (like it is now eventually anyway > when you start with a fresh image). > 2) We don't need to store the *current* version on disk. Compressed in > memory. Yes, that is what progress brings… > 3) Disk space is so cheap it is not even funny. > -> we will just have a dedicated log. And we can even store Objects… > > And then we can leverage the extreme simplicity of the resulting scheme.. > simplicity is an amazing thing. (Or the > contrary: I think people understate the effects of complexity). > > Marcus
Re: [Pharo-project] Trying to understand DateAndTime
On Apr 27, 2013, at 6:33 PM, Nicolas Cellier
wrote:
> Since DateAndTime comment is out of date (sic !) and current implementation
> seems not free of bug, here is an effort to summarize and understand the
> whole thing, let's call this a review.
Thanks this is a great initiative!
> Please tell me where my interpretations are wrong.
>
> 1) The DateAndTime is stored internally as
> - a point in UTC time (julianDayNumber, seconds, nanos)
> - an offset from UTC (a Duration) denoting the local time zone
>
> 2) The ticks method returns the UTC part {julianDayNumber. seconds. nanos}
>
> 3) DateAndTime print themselves in local time using the offset
>
> 4) other methods (with some exceptions) return the local dateAndTime parts
> (year month day hours minutes seconds)
>
> Exceptions are:
> - secondsSinceMidnight (which should be renamed secondsSinceMidnightUTC IMO,
> even if the method is classified private)
> - julianDayNumberUTC as the name tells
>
> So far so good (but secondsSinceMidnight which is error prone)
>
> What I find strange:
> - #hash uses the offset... Why ???
>
> d1 := DateAndTime now.
> d2 := d1 offset: d1 offset + 1 hours.
> {
> d1 = d2.
> d1 hash = d2 hash.
> }
> gives #(true false), a clue?
>
> - #< compares julianDayNumber (the UTC inst. var.) with otherDate
> julianDayNumber (with otherDate local offset) which seems wrong, it should
> better use julianDayNumberUTC or (normalized) ticks.
>
> - #= could be simplified and accelerated if using #hasEqualTicks: (if the
> ticks are correctly normalized though which would be the case since
> #ticks:offset: does, unfortunately #setJdn:seconds:nanos:offset: does not).
>
> Some senders of #setJdn:seconds:nanos:offset: don't normalize the
> day/seconds/nanos, though it should be their responsibility (DateAndTime
> todayAtMilliSeconds: xxx) (DateAndTime todayAtNanoSeconds: xxx), not counting
> year:month:day:hour:minute:second:nanoSecond:offset: which does not either
> (many senders...).
> Maybe we should better let the normalization responsibility to
> #setJdn:seconds:nanos:offset:.
>
> It remain to analyze the conversion protocol (asYear etc...) which seems to
> use the local time year, but I don't understand the whole Timespan thing
> right now (why DateAndTime now asYear starts now, and not on january 1st?).
>
> Nicolas
>
>
Re: [Pharo-project] [Ann] TxText. New text editor done!
Hi denis Alain is gone on vacation but it told me that if you code scale he will throw away what he did :) May be the decorators that alain wrote can be merged. In any case this is excellent to get a better system. Stef On Apr 27, 2013, at 5:17 PM, Denis Kudriashov wrote: > I should say it is not difficult to do with current design. I were > think about it and current layout building logic requires little > changes, maybe just one spesific method. > > But there is cases where any text change required rebuilding full > layout. Fo example, single line text with wrapping mode. > > > 2013/4/27, Igor Stasenko : >> Very impressive progress, Denis! :) >> >> I going to finish low-level stuff in Athens (path approximation / >> point location) >> and then go straight to text rendering with existing Text. >> Next stage will be to take TxText model and provide rendering for it >> with Athens, >> as well as review the code. >> >> About text editing and re-layout. >> It should be possible that any local update (which affecting only >> single character span or multiple adjusted character spans will >> require only local recalculations of text layout). Otherwise there is >> no reason why in our model we don't keep whole text in single big >> buffer (like Text does). >> Splitting text on multiple spans was the reason to make local layout >> updates possible. >> But i know it is not that easy to do :) >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> >
Re: [Pharo-project] Opal Decompiler status
On Apr 27, 2013, at 8:01 PM, Nicolas Cellier wrote: > Right, if you embed source along with CompiledMethod (to handle the case when > the CompiledMethod has been replaced but one of its block of code is still > used), then you don't need Decompiler in the first place. > > Nonetheless, I would remove the .sources but not the .changes. The .changes > is not only a source code repository (that feature can go away if you want), > it's before all a change log, an insurance to retrieve some change when > everything else failed (image crashed or worse corrupted image won't > restart). You can make the insurance optional if you want, but please > continue to provide an equivalent service. A change file is the most simple > thing that could possibly work IMO. But this is another thread. > Yes, we have a solution for that… the thing is that the .changes has 3 roles. In the 1978, it was very clever to design one extremely memory efficient mechanism to kill all three: 1) keep a history of all the accepted method sources in the image (see "versions") 2) store the code on disk efficiently with no duplications (They counted those extremely expensive disks in the one-diget Megabytes back then). 3) have transaction log for the source code in case of image crash. Now today, we can solve all three using three different methods: 1) we will just keep the accepted methods in memory until you commit to monticello/git (in case of git one can even commit all the intermediates, for MC one would just commit the latest). after the in-image history is pruned (like it is now eventually anyway when you start with a fresh image). 2) We don't need to store the *current* version on disk. Compressed in memory. Yes, that is what progress brings… 3) Disk space is so cheap it is not even funny. -> we will just have a dedicated log. And we can even store Objects… And then we can leverage the extreme simplicity of the resulting scheme.. simplicity is an amazing thing. (Or the contrary: I think people understate the effects of complexity). Marcus
Re: [Pharo-project] Opal Decompiler status
Right, if you embed source along with CompiledMethod (to handle the case when the CompiledMethod has been replaced but one of its block of code is still used), then you don't need Decompiler in the first place. Nonetheless, I would remove the .sources but not the .changes. The .changes is not only a source code repository (that feature can go away if you want), it's before all a change log, an insurance to retrieve some change when everything else failed (image crashed or worse corrupted image won't restart). You can make the insurance optional if you want, but please continue to provide an equivalent service. A change file is the most simple thing that could possibly work IMO. But this is another thread. Concerning the temp mapping, I agree, we should not compete with Eliot, he's very tough at tedious tasks, our only weapon is lazyness, lazyness often leads to efficiency ;) I'm curious to check how you handled this complex part with AST when I'll have more time to dig. 2013/4/27 Marcus Denker > > On Apr 27, 2013, at 6:42 PM, Nicolas Cellier < > nicolas.cellier.aka.n...@gmail.com> wrote: > > > Thanks Marcus. > > I'm among the skepticals concerning the AST, but I'd like to be proven > wrong, because AST level would certainly simplify things a lot. > > My main reserve is that interruption can occur at BC level, so for > debugging purpose, what are your plans? > > Will you move the PC at some AST node boundary (if it is possible given > side effects of some BC)? > > > For the Debugger, everything stays as it is (until Pharo 4 or so)… if you > look at it, the current Debugger never decompiles if there is source > available. > It *compiles* to get > -> the mapping BC -> text > -> the information how temporary variables in the byte code are > actually related to temps in the source. > (this is very complex, temps can be e.g. stored on the heap if > they are written to in a closure, and when they are just > read they have a different offset in each closure they are > in. Conversely, some temps in the byte code are used > to store the array that hold the variables that are on the > heap…) > > The old compiler recorded mappings while compiling that where encoded… > quite complex, at least for my tiny brain. > > So the new just keeps the AST annotated with all the needed infos, this is > much easier to debug (and we do have the > memory these days, and as we cache the AST, it's even fast). > > So the debugger needs the compiler. The decompiler now exists just to make > text so that we can call the compiler > in the case there is no .sources. The debugger *always* compiles to get > the mappings, as soon as there is source code > the decompiler will never be used. (and even if the decompiler is used, > the compiler is called right after on it's results so > one can record the mappings). > > So if you make sure there is always source-code (or a representation with > the right amount of meta data), you don't need the decompiler. > > So at the start it will be the source code. And yes, this takes memory. > But we are in 2013 and if we have one thing than it's memory. > (the $25 Raspi comes with 256MB, the $35 with 512MB…). > > We could have shipped 2.0 with 8MB of useless Monticello meta data and > nobody would have even realized it. (like we > have now megabytes of fonts in the image…). Yet the source is special… I > really wonder why. > > (And yes, there should be solutions to not need unused data in main memory > and solutions to share across multiple images > data that is the same… but for all kinds of stuff, not just source code). > > Marcus >
Re: [Pharo-project] Opal Decompiler status
On Apr 27, 2013, at 6:42 PM, Nicolas Cellier wrote: > Thanks Marcus. > I'm among the skepticals concerning the AST, but I'd like to be proven wrong, > because AST level would certainly simplify things a lot. > My main reserve is that interruption can occur at BC level, so for debugging > purpose, what are your plans? > Will you move the PC at some AST node boundary (if it is possible given side > effects of some BC)? > For the Debugger, everything stays as it is (until Pharo 4 or so)… if you look at it, the current Debugger never decompiles if there is source available. It *compiles* to get -> the mapping BC -> text -> the information how temporary variables in the byte code are actually related to temps in the source. (this is very complex, temps can be e.g. stored on the heap if they are written to in a closure, and when they are just read they have a different offset in each closure they are in. Conversely, some temps in the byte code are used to store the array that hold the variables that are on the heap…) The old compiler recorded mappings while compiling that where encoded… quite complex, at least for my tiny brain. So the new just keeps the AST annotated with all the needed infos, this is much easier to debug (and we do have the memory these days, and as we cache the AST, it's even fast). So the debugger needs the compiler. The decompiler now exists just to make text so that we can call the compiler in the case there is no .sources. The debugger *always* compiles to get the mappings, as soon as there is source code the decompiler will never be used. (and even if the decompiler is used, the compiler is called right after on it's results so one can record the mappings). So if you make sure there is always source-code (or a representation with the right amount of meta data), you don't need the decompiler. So at the start it will be the source code. And yes, this takes memory. But we are in 2013 and if we have one thing than it's memory. (the $25 Raspi comes with 256MB, the $35 with 512MB…). We could have shipped 2.0 with 8MB of useless Monticello meta data and nobody would have even realized it. (like we have now megabytes of fonts in the image…). Yet the source is special… I really wonder why. (And yes, there should be solutions to not need unused data in main memory and solutions to share across multiple images data that is the same… but for all kinds of stuff, not just source code). Marcus
Re: [Pharo-project] Opal Decompiler status
Thanks Marcus. I'm among the skepticals concerning the AST, but I'd like to be proven wrong, because AST level would certainly simplify things a lot. My main reserve is that interruption can occur at BC level, so for debugging purpose, what are your plans? Will you move the PC at some AST node boundary (if it is possible given side effects of some BC)? 2013/4/27 Marcus Denker > > On Apr 27, 2013, at 5:59 PM, Marcus Denker > wrote:. > > > >> Could we have a primer on what remains to do on the Opal front? > >> > > > > > > -> debug BC-IR->AST->text mapping more (lots of it working already) > > -> debug temp variable lookup in optimized blocks in the debugger > (almost there, too) > > -> Go through all the test for the old Compiler and port them to the new. > > -> Better compiler API and refactor the whole system to use it > > (but keep a backward compatible API at least to some extend) > > > All the TODOs are in the bug tracker, Project "Compiler (Opal)". > > There are right now 29 Issues. > > Marcus >
[Pharo-project] Trying to understand DateAndTime
Since DateAndTime comment is out of date (sic !) and current implementation
seems not free of bug, here is an effort to summarize and understand the
whole thing, let's call this a review.
Please tell me where my interpretations are wrong.
1) The DateAndTime is stored internally as
- a point in UTC time (julianDayNumber, seconds, nanos)
- an offset from UTC (a Duration) denoting the local time zone
2) The ticks method returns the UTC part {julianDayNumber. seconds. nanos}
3) DateAndTime print themselves in local time using the offset
4) other methods (with some exceptions) return the local dateAndTime parts
(year month day hours minutes seconds)
Exceptions are:
- secondsSinceMidnight (which should be renamed secondsSinceMidnightUTC
IMO, even if the method is classified private)
- julianDayNumberUTC as the name tells
So far so good (but secondsSinceMidnight which is error prone)
What I find strange:
- #hash uses the offset... Why ???
d1 := DateAndTime now.
d2 := d1 offset: d1 offset + 1 hours.
{
d1 = d2.
d1 hash = d2 hash.
}
gives #(true false), a clue?
- #< compares julianDayNumber (the UTC inst. var.) with otherDate
julianDayNumber (with otherDate local offset) which seems wrong, it should
better use julianDayNumberUTC or (normalized) ticks.
- #= could be simplified and accelerated if using #hasEqualTicks: (if the
ticks are correctly normalized though which would be the case since
#ticks:offset: does, unfortunately #setJdn:seconds:nanos:offset: does not).
Some senders of #setJdn:seconds:nanos:offset: don't normalize the
day/seconds/nanos, though it should be their responsibility (DateAndTime
todayAtMilliSeconds: xxx) (DateAndTime todayAtNanoSeconds: xxx), not
counting year:month:day:hour:minute:second:nanoSecond:offset: which does
not either (many senders...).
Maybe we should better let the normalization responsibility to
#setJdn:seconds:nanos:offset:.
It remain to analyze the conversion protocol (asYear etc...) which seems to
use the local time year, but I don't understand the whole Timespan thing
right now (why DateAndTime now asYear starts now, and not on january 1st?).
Nicolas
Re: [Pharo-project] Opal Decompiler status
On Apr 27, 2013, at 5:59 PM, Marcus Denker wrote:. > >> Could we have a primer on what remains to do on the Opal front? >> > > > -> debug BC-IR->AST->text mapping more (lots of it working already) > -> debug temp variable lookup in optimized blocks in the debugger (almost > there, too) > -> Go through all the test for the old Compiler and port them to the new. > -> Better compiler API and refactor the whole system to use it > (but keep a backward compatible API at least to some extend) All the TODOs are in the bug tracker, Project "Compiler (Opal)". There are right now 29 Issues. Marcus
Re: [Pharo-project] Opal Decompiler status
On Apr 27, 2013, at 5:26 PM, Nicolas Cellier wrote: > I see that the OCFakeDecompiler which uses the old and horrible (*) > Decompiler is still in use. > Though, IRBytecodeDecompiler seems already quite advanced. The idea actually is to not have a decompiler BC->AST. We have one BC->IR for manipulating things on the byte code level (e.g. he new class builder will use it). BC->IR->BC is working and tested after every commit. But on the AST level, idea is to have a higher level representation of code always available. (compressed ASTs in the long term, compressed source as the intermediate solution). Yes, I know that people will be highly skeptical about this. Up to the point that I even don't expect to convince anyone other than by actually showing a working version… This goes hand-in-hand with the "one file" image: just one .pharo image, no .sources, no .changes. (Which real conservative people will not like, either). We need to see how fast this progresses, if we see that it will not be ready for 3.0, we should add a IR->AST decompiler, but I hope the alternative will show that it is not necessary. > Could we have a primer on what remains to do on the Opal front? > -> debug BC-IR->AST->text mapping more (lots of it working already) -> debug temp variable lookup in optimized blocks in the debugger (almost there, too) -> Go through all the test for the old Compiler and port them to the new. -> Better compiler API and refactor the whole system to use it (but keep a backward compatible API at least to some extend) Marcus
[Pharo-project] Opal Decompiler status
I see that the OCFakeDecompiler which uses the old and horrible (*) Decompiler is still in use. Though, IRBytecodeDecompiler seems already quite advanced. Could we have a primer on what remains to do on the Opal front? (*) just look number of inst vars, count how many times their state change, and measure average method length for an approximate definition of horrible
Re: [Pharo-project] [Ann] TxText. New text editor done!
Sean P. DeNigris wrote > You're my new best friend :) The cursor is an actual Morph (TxCursorMorph) instead of magic conjured up my Paragraph!!! All my other friends are fired, they've never given me a present this nice :) Also, please add me to the repo. I have a small fix (TxCursorMorph should show cursorColor instead of defaultColor) - Cheers, Sean -- View this message in context: http://forum.world.st/Ann-TxText-New-text-editor-done-tp4683876p4683990.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] [Ann] TxText. New text editor done!
I should say it is not difficult to do with current design. I were think about it and current layout building logic requires little changes, maybe just one spesific method. But there is cases where any text change required rebuilding full layout. Fo example, single line text with wrapping mode. 2013/4/27, Igor Stasenko : > Very impressive progress, Denis! :) > > I going to finish low-level stuff in Athens (path approximation / > point location) > and then go straight to text rendering with existing Text. > Next stage will be to take TxText model and provide rendering for it > with Athens, > as well as review the code. > > About text editing and re-layout. > It should be possible that any local update (which affecting only > single character span or multiple adjusted character spans will > require only local recalculations of text layout). Otherwise there is > no reason why in our model we don't keep whole text in single big > buffer (like Text does). > Splitting text on multiple spans was the reason to make local layout > updates possible. > But i know it is not that easy to do :) > > > -- > Best regards, > Igor Stasenko. > >
Re: [Pharo-project] [Ann] TxText. New text editor done!
OMG, TxTextMorph can grow horizontally. You're my new best friend :) - Cheers, Sean -- View this message in context: http://forum.world.st/Ann-TxText-New-text-editor-done-tp4683876p4683988.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] [Ann] TxText. New text editor done!
Denis Kudriashov wrote
> You can load configuration from
> http://www.smalltalkhub.com/#!/~sig/TxText.
For the recreationally-inclined, like myself ;)
Gofer it
url: 'http://www.smalltalkhub.com/#!/~sig/TxText';
package: 'ConfigurationOfTxText';
load.
((Smalltalk at: #ConfigurationOfTxText) project version: '0.6') load:
#('ALL').
-
Cheers,
Sean
--
View this message in context:
http://forum.world.st/Ann-TxText-New-text-editor-done-tp4683876p4683987.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] [Ann] TxText. New text editor done!
Very impressive progress, Denis! :) I going to finish low-level stuff in Athens (path approximation / point location) and then go straight to text rendering with existing Text. Next stage will be to take TxText model and provide rendering for it with Athens, as well as review the code. About text editing and re-layout. It should be possible that any local update (which affecting only single character span or multiple adjusted character spans will require only local recalculations of text layout). Otherwise there is no reason why in our model we don't keep whole text in single big buffer (like Text does). Splitting text on multiple spans was the reason to make local layout updates possible. But i know it is not that easy to do :) -- Best regards, Igor Stasenko.
Re: [Pharo-project] [update 3.0] #30066
stephane ducasse wrote > marcus do you know why the diff does not work with SmalltalkHub? It works sometimes. It seems that it works when the ancestors are present and produces a confusing error message when they are not... - Cheers, Sean -- View this message in context: http://forum.world.st/update-3-0-30066-tp4683816p4683983.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] [Ann] TxText. New text editor done!
2013/4/27 Denis Kudriashov > 2013/4/27 Denis Kudriashov > >> 2013/4/27 Denis Kudriashov >> >>> 2013/4/27 stephane ducasse >>> Nice! Denis did you see the benchs that doru tried to see if we can use Rubric? Because it is interesting to see if we can load and manipulate really large file. Now it would be good that alain releases Rubric with a stable version and check how to take advantage of the new TextMorph. I saw his post. >>> And just now I check this test with TxTextMorph with unwrapped strategy. >>> Similar results like at Rubric test. nearly 30 secs. >>> I generate 50 mb string with almost million lines: >>> TxModel building get 10 seconds. Layout building get 20 seconds. >>> >>> If you want repeat this test you should not use #newTextContents: >>> method. You should build text model manually and put it at morph by >>> #textModel:. >>> #newTextContents: method should be optimized. When I try test with >>> #newTextContents: it was hang on very long time and I stop it. >>> >>> >> And now text editing has no optimization. After each edit full text >> layout rebuilt. So pressing some character in our test take another 20 >> seconds. >> It should be just fixed >> > > And #drawOn: method should be optimized too. I think it is not difficult > task. > Now each line try to draw on canvas. But morph should draw only visible > lines > Drawing fixed. I upload new TxText-Layout version > > >> >>> Stef On Apr 26, 2013, at 11:19 PM, Denis Kudriashov wrote: Hi guys. I'm happy to announce that new text editor based on new text model done. You can load configuration from http://www.smalltalkhub.com/#!/~sig/TxText. Last version: 0.6. See class side example methods. What available now in TxTextMorph: - cursor navigation with move left, right, down, up and mouse click - text selection with move left, right, down, up and mouse movement - editing by keyboard input - text wrap - #addCursor/#removeCursor - #enableSelection. - #beEditable - all keyboard interractions based on shortcuts Little details about navigation and editing: There is TxEditor object which know about cursor position and text selection. Text morph ask him to perform all navigation and editing behaviour. It has cursorMode which knows how to change editor selection when cursor moved. Editor delegates all move actions to cursorPosition by #doesNotUnderstand method. It is simplified adding new navigation methods. For example see TxTextMorph>>enableSelection aTxTextMorph>>moveEditorOn: Character arrowLeft by: #moveLeft. This expression adds two shortcuts: to move editor left and to select text left (when selectionModeModifier active). What next: - Remains standart navigation and editing features like copy/paste, move to line end, to text end and etc. - halo menu items to edit text and layout properties - Edit decorators to get mask behaviour like "(999)***-**-**", pretty numbers like "1'000'000", secrete field like "***" - Value specs to filter inserted text (only numbers, only english and etc) There are some problems with focus behaviour now. And drawing text morph with transparent back color works bad. It will be cool if somebody with good knowledge at this topics can fix it. Best regards, Denis >>> >> >
Re: [Pharo-project] Pharo 3.0 TestRunner results
On Apr 27, 2013, at 3:12 PM, Benoit St-Jean wrote: > I don't know if that's of any help (or if it's been reported before) but here > are the results of TestRunner (against all tests) on a Pharo3.0 (Latest > update: #30021) image on Windows XP SP3. Can you check with the latest 3.0? it should be 30068 We do run all tests on all three platforms after every change: https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/ But this is headless and there can be strange differences between the two. Marcus
[Pharo-project] Pharo 3.0 TestRunner results
I don't know if that's of any help (or if it's been reported before) but here are the results of TestRunner (against all tests) on a Pharo3.0 (Latest update: #30021) image on Windows XP SP3. Btw, timezone here is GMT -5:00 (Montreal). See results in attached file. Hope this helps. - Benoit St-Jean Yahoo! Messenger: bstjean Blogue: endormitoire.wordpress.com A standpoint is an intellectual horizon of radius zero. (Albert Einstein) 9645 run, 9605 passes, 2 skipped, 28 expected failures, 8 failures, 4 errors, 0 unexpected passes Failures: ReleaseTest>>#testObsoleteBehaviors DateTest>>#testDateAndTimeNow TimeStampTest>>#testMinusSecondsOverMidnight PluggableSetTest>>#testAllSetsAreHealthy DateTest>>#testNew RBSmalllintTest>>#testLongMethods IdentitySetTest>>#testAllSetsAreHealthy ReleaseTest>>#testObsoleteClasses Errors: MCStReaderTest>>#testCommentWithStyle MCStReaderTest>>#testMethodWithStyle SmalllintManifestCheckerTest>>#testFalsePositiveOf RBSmalllintTest>>#testEndTrueFalse
[Pharo-project] [regression reporter]regression occurred
https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=win/88/ 1 regressions found. KernelTests.Classes.ClassDescriptionTest.testUnCategorizedMethods
[Pharo-project] [regression reporter]regression occurred
https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=mac/88/ 1 regressions found. KernelTests.Classes.ClassDescriptionTest.testUnCategorizedMethods
[Pharo-project] [regression reporter]regression occurred
https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=linux/88/ 1 regressions found. KernelTests.Classes.ClassDescriptionTest.testUnCategorizedMethods
[Pharo-project] [update 3.0] #30068
30068 - 10402 Cannot print TestCase when testSelector is not set https://pharo.fogbugz.com/f/cases/10402 10421 Move reformatMethodAt: --> #reformat on CompiledMethod https://pharo.fogbugz.com/f/cases/10421 10422 cleanup unused code Compiler more https://pharo.fogbugz.com/f/cases/10422 Diff information: http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Traits-MarcusDenker.479 http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/SUnit-Core-MarcusDenker.69 http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Kernel-MarcusDenker.1386 http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Compiler-MarcusDenker.405
[Pharo-project] Fwd: IWST 2013 Call for papers
Begin forwarded message: > From: Alain Plantec > Subject: Fwd: IWST 2013 Call for papers > Date: 27 avril 2013 14:00:40 UTC+02:00 > To: squeak-...@lists.squeakfoundation.org > Cc: Alain Plantec , Board ESUG , > Loic Lagadec > > > > Begin forwarded message: > >> From: Alain Plantec >> Subject: IWST 2013 Call for papers >> Date: 27 avril 2013 13:59:40 UTC+02:00 >> To: esug-l...@lists.esug.org >> Cc: Alain Plantec , Loic Lagadec >> , Board ESUG >> >> Dear smalltalkers, >> >> You will find below the CFP for the International Workshop on Smalltalk >> Technologies 2013. >> Please disseminate through your own mailing lists. We also hope you will be >> able to submit some of your contributions. >> >> Best regards, >> Program Co-chairs >> Loïc Lagadec, Alain Plantec >> Lab-STICC/CNRS, Université de Bretagne Occidentale >> >> >> >> International Workshop on Smalltalk Technologies 2013 >> >> September 10, 2013 >> Annecy, France >> >> ESUG 2013 joint event >> >> -- Important dates -- >> >> Submission deadline: June 15, 2013 >> >> Notification deadline: July 15, 2013 >> >> Workshop : September 10, 2013 >> >> All accepted papers will be published in ACM DL (ACM In-Cooperation to be >> confirmed). >> >> >> -- Goals and scopes -- >> >> The goals of the workshop is to create a forum around advances or experience >> in Smalltalk and to trigger discussions and exchanges of ideas. Participants >> are invited to submit research articles. We will not enforce any length >> restriction. However we expect papers of two kinds: >> >> Short position papers describing emerging ideas. >> Long research papers with deeper description of experiments and of research >> results. >> Topics >> >> We welcome contributions on all aspects, theoretical as well as practical, >> of Smalltalk related topics such as: >> • Aspect-oriented programming, >> • Design patterns, >> • Experience reports, >> • Frameworks, >> • Implementation, new dialects or languages implemented in Smalltalk, >> • Interaction with other languages, >> • Meta-programming and Meta-modeling, >> • Tools >> >> Links home page: http://www.esug.org/Conferences/2013/InternationalWorkshop >> >> Publication Both submissions and final papers must be prepared using the ACM >> SIGPLAN 10 point format. Templates for Word and LaTeX are available at >> http://www.acm.org/sigs/sigplan/authorInformation.htm. This site also >> contains links to useful informations on how to write effective submissions. >> >> Program chairs Loïc Lagadec and Alain Plantec (LabSticc CACS/CNRS, >> University of Brest, France) >> > >
Re: [Pharo-project] [Ann] TxText. New text editor done!
2013/4/27 Denis Kudriashov > 2013/4/27 Denis Kudriashov > >> 2013/4/27 stephane ducasse >> >>> Nice! >>> Denis did you see the benchs that doru tried to see if we can use Rubric? >>> Because it is interesting to see if we can load and manipulate really >>> large file. >>> >>> Now it would be good that alain releases Rubric with a stable version >>> and check how to take advantage of the new TextMorph. >>> >>> I saw his post. >> And just now I check this test with TxTextMorph with unwrapped strategy. >> Similar results like at Rubric test. nearly 30 secs. >> I generate 50 mb string with almost million lines: >> TxModel building get 10 seconds. Layout building get 20 seconds. >> >> If you want repeat this test you should not use #newTextContents: method. >> You should build text model manually and put it at morph by #textModel:. >> #newTextContents: method should be optimized. When I try test with >> #newTextContents: it was hang on very long time and I stop it. >> >> > And now text editing has no optimization. After each edit full text layout > rebuilt. So pressing some character in our test take another 20 seconds. > It should be just fixed > And #drawOn: method should be optimized too. I think it is not difficult task. Now each line try to draw on canvas. But morph should draw only visible lines > >> >>> Stef >>> >>> On Apr 26, 2013, at 11:19 PM, Denis Kudriashov >>> wrote: >>> >>> Hi guys. >>> >>> I'm happy to announce that new text editor based on new text model done. >>> You can load configuration from >>> http://www.smalltalkhub.com/#!/~sig/TxText. Last version: 0.6. >>> See class side example methods. >>> >>> What available now in TxTextMorph: >>> - cursor navigation with move left, right, down, up and mouse click >>> - text selection with move left, right, down, up and mouse movement >>> - editing by keyboard input >>> - text wrap >>> - #addCursor/#removeCursor >>> - #enableSelection. >>> - #beEditable >>> - all keyboard interractions based on shortcuts >>> >>> Little details about navigation and editing: >>> There is TxEditor object which know about cursor position and text >>> selection. Text morph ask him to perform all navigation and editing >>> behaviour. >>> It has cursorMode which knows how to change editor selection when cursor >>> moved. Editor delegates all move actions to cursorPosition by >>> #doesNotUnderstand method. It is simplified adding new navigation methods. >>> For example see TxTextMorph>>enableSelection >>> >>> aTxTextMorph>>moveEditorOn: Character arrowLeft by: #moveLeft. >>> >>> This expression adds two shortcuts: to move editor left and to select >>> text left (when selectionModeModifier active). >>> >>> What next: >>> - Remains standart navigation and editing features like copy/paste, move >>> to line end, to text end and etc. >>> - halo menu items to edit text and layout properties >>> - Edit decorators to get mask behaviour like "(999)***-**-**", pretty >>> numbers like "1'000'000", secrete field like "***" >>> - Value specs to filter inserted text (only numbers, only english and >>> etc) >>> >>> There are some problems with focus behaviour now. And drawing text morph >>> with transparent back color works bad. It will be cool if somebody with >>> good knowledge at this topics can fix it. >>> >>> Best regards, >>> Denis >>> >>> >>> >> >
Re: [Pharo-project] [Ann] TxText. New text editor done!
With wrapping mode layout building take 27 seconds which is not too much than without wrapping. But it get 3.5 times more layout lines. (230 000 lines without wrapping and 750 000 with wrapping in my test) 2013/4/27 Denis Kudriashov > 2013/4/27 Denis Kudriashov > >> 2013/4/27 stephane ducasse >> >>> Nice! >>> Denis did you see the benchs that doru tried to see if we can use Rubric? >>> Because it is interesting to see if we can load and manipulate really >>> large file. >>> >>> Now it would be good that alain releases Rubric with a stable version >>> and check how to take advantage of the new TextMorph. >>> >>> I saw his post. >> And just now I check this test with TxTextMorph with unwrapped strategy. >> Similar results like at Rubric test. nearly 30 secs. >> I generate 50 mb string with almost million lines: >> TxModel building get 10 seconds. Layout building get 20 seconds. >> > > I found that Tudor wrote about 15 million lines. > So I change my test and now I have OutOfMemotyWarning. It raised on > splitting given string on lines. Obviously building text model should be > optimized by work with stream. > >
Re: [Pharo-project] [Ann] TxText. New text editor done!
Thanks for your energy, alain told me that he will also have a look. This is good to see movement from this front. Having a scalable texteditor with rich editing capabilities (icons, line number) is important for Moose and synectique. Also the new generation code browser will benefit from this new TextMorph. Stef On Apr 27, 2013, at 12:54 PM, Denis Kudriashov wrote: > 2013/4/27 Denis Kudriashov > 2013/4/27 stephane ducasse > Nice! > Denis did you see the benchs that doru tried to see if we can use Rubric? > Because it is interesting to see if we can load and manipulate really large > file. > > Now it would be good that alain releases Rubric with a stable version and > check how to take advantage of the new TextMorph. > > I saw his post. > And just now I check this test with TxTextMorph with unwrapped strategy. > Similar results like at Rubric test. nearly 30 secs. > I generate 50 mb string with almost million lines: > TxModel building get 10 seconds. Layout building get 20 seconds. > > I found that Tudor wrote about 15 million lines. > So I change my test and now I have OutOfMemotyWarning. It raised on splitting > given string on lines. Obviously building text model should be optimized by > work with stream. >
Re: [Pharo-project] [Ann] TxText. New text editor done!
2013/4/27 Denis Kudriashov > 2013/4/27 stephane ducasse > >> Nice! >> Denis did you see the benchs that doru tried to see if we can use Rubric? >> Because it is interesting to see if we can load and manipulate really >> large file. >> >> Now it would be good that alain releases Rubric with a stable version and >> check how to take advantage of the new TextMorph. >> >> I saw his post. > And just now I check this test with TxTextMorph with unwrapped strategy. > Similar results like at Rubric test. nearly 30 secs. > I generate 50 mb string with almost million lines: > TxModel building get 10 seconds. Layout building get 20 seconds. > I found that Tudor wrote about 15 million lines. So I change my test and now I have OutOfMemotyWarning. It raised on splitting given string on lines. Obviously building text model should be optimized by work with stream.
Re: [Pharo-project] [Ann] TxText. New text editor done!
On 27 avr. 2013, at 12:39, Denis Kudriashov wrote: > 2013/4/27 stephane ducasse > Nice! > Denis did you see the benchs that doru tried to see if we can use Rubric? > Because it is interesting to see if we can load and manipulate really large > file. > > Now it would be good that alain releases Rubric with a stable version and > check how to take advantage of the new TextMorph. > > I saw his post. > And just now I check this test with TxTextMorph with unwrapped strategy. > Similar results like at Rubric test. nearly 30 secs. > I generate 50 mb string with almost million lines: > TxModel building get 10 seconds. Layout building get 20 seconds. impressive! I will have a look. Thanks Alain > > If you want repeat this test you should not use #newTextContents: method. You > should build text model manually and put it at morph by #textModel:. > #newTextContents: method should be optimized. When I try test with > #newTextContents: it was hang on very long time and I stop it. > > > Stef > > On Apr 26, 2013, at 11:19 PM, Denis Kudriashov wrote:
Re: [Pharo-project] [Ann] TxText. New text editor done!
2013/4/27 Denis Kudriashov > 2013/4/27 stephane ducasse > >> Nice! >> Denis did you see the benchs that doru tried to see if we can use Rubric? >> Because it is interesting to see if we can load and manipulate really >> large file. >> >> Now it would be good that alain releases Rubric with a stable version and >> check how to take advantage of the new TextMorph. >> >> I saw his post. > And just now I check this test with TxTextMorph with unwrapped strategy. > Similar results like at Rubric test. nearly 30 secs. > I generate 50 mb string with almost million lines: > TxModel building get 10 seconds. Layout building get 20 seconds. > > If you want repeat this test you should not use #newTextContents: method. > You should build text model manually and put it at morph by #textModel:. > #newTextContents: method should be optimized. When I try test with > #newTextContents: it was hang on very long time and I stop it. > > And now text editing has no optimization. After each edit full text layout rebuilt. So pressing some character in our test take another 20 seconds. It should be just fixed > > >> Stef >> >> On Apr 26, 2013, at 11:19 PM, Denis Kudriashov >> wrote: >> >> Hi guys. >> >> I'm happy to announce that new text editor based on new text model done. >> You can load configuration from >> http://www.smalltalkhub.com/#!/~sig/TxText. Last version: 0.6. >> See class side example methods. >> >> What available now in TxTextMorph: >> - cursor navigation with move left, right, down, up and mouse click >> - text selection with move left, right, down, up and mouse movement >> - editing by keyboard input >> - text wrap >> - #addCursor/#removeCursor >> - #enableSelection. >> - #beEditable >> - all keyboard interractions based on shortcuts >> >> Little details about navigation and editing: >> There is TxEditor object which know about cursor position and text >> selection. Text morph ask him to perform all navigation and editing >> behaviour. >> It has cursorMode which knows how to change editor selection when cursor >> moved. Editor delegates all move actions to cursorPosition by >> #doesNotUnderstand method. It is simplified adding new navigation methods. >> For example see TxTextMorph>>enableSelection >> >> aTxTextMorph>>moveEditorOn: Character arrowLeft by: #moveLeft. >> >> This expression adds two shortcuts: to move editor left and to select >> text left (when selectionModeModifier active). >> >> What next: >> - Remains standart navigation and editing features like copy/paste, move >> to line end, to text end and etc. >> - halo menu items to edit text and layout properties >> - Edit decorators to get mask behaviour like "(999)***-**-**", pretty >> numbers like "1'000'000", secrete field like "***" >> - Value specs to filter inserted text (only numbers, only english and etc) >> >> There are some problems with focus behaviour now. And drawing text morph >> with transparent back color works bad. It will be cool if somebody with >> good knowledge at this topics can fix it. >> >> Best regards, >> Denis >> >> >> >
Re: [Pharo-project] [Ann] TxText. New text editor done!
2013/4/27 stephane ducasse > Nice! > Denis did you see the benchs that doru tried to see if we can use Rubric? > Because it is interesting to see if we can load and manipulate really > large file. > > Now it would be good that alain releases Rubric with a stable version and > check how to take advantage of the new TextMorph. > > I saw his post. And just now I check this test with TxTextMorph with unwrapped strategy. Similar results like at Rubric test. nearly 30 secs. I generate 50 mb string with almost million lines: TxModel building get 10 seconds. Layout building get 20 seconds. If you want repeat this test you should not use #newTextContents: method. You should build text model manually and put it at morph by #textModel:. #newTextContents: method should be optimized. When I try test with #newTextContents: it was hang on very long time and I stop it. > Stef > > On Apr 26, 2013, at 11:19 PM, Denis Kudriashov > wrote: > > Hi guys. > > I'm happy to announce that new text editor based on new text model done. > You can load configuration from http://www.smalltalkhub.com/#!/~sig/TxText. > Last version: 0.6. > See class side example methods. > > What available now in TxTextMorph: > - cursor navigation with move left, right, down, up and mouse click > - text selection with move left, right, down, up and mouse movement > - editing by keyboard input > - text wrap > - #addCursor/#removeCursor > - #enableSelection. > - #beEditable > - all keyboard interractions based on shortcuts > > Little details about navigation and editing: > There is TxEditor object which know about cursor position and text > selection. Text morph ask him to perform all navigation and editing > behaviour. > It has cursorMode which knows how to change editor selection when cursor > moved. Editor delegates all move actions to cursorPosition by > #doesNotUnderstand method. It is simplified adding new navigation methods. > For example see TxTextMorph>>enableSelection > > aTxTextMorph>>moveEditorOn: Character arrowLeft by: #moveLeft. > > This expression adds two shortcuts: to move editor left and to select text > left (when selectionModeModifier active). > > What next: > - Remains standart navigation and editing features like copy/paste, move > to line end, to text end and etc. > - halo menu items to edit text and layout properties > - Edit decorators to get mask behaviour like "(999)***-**-**", pretty > numbers like "1'000'000", secrete field like "***" > - Value specs to filter inserted text (only numbers, only english and etc) > > There are some problems with focus behaviour now. And drawing text morph > with transparent back color works bad. It will be cool if somebody with > good knowledge at this topics can fix it. > > Best regards, > Denis > > >
Re: [Pharo-project] [Ann] TxText. New text editor done!
On 27 Apr 2013, at 10:11, Denis Kudriashov wrote: > 2013/4/27 Sven Van Caekenberghe > > On 27 Apr 2013, at 10:02, Denis Kudriashov wrote: > > > Hi > > > > 2013/4/27 Sven Van Caekenberghe > > Hi Denis, > > > > On 26 Apr 2013, at 23:19, Denis Kudriashov wrote: > > > > > I'm happy to announce that new text editor based on new text model done. > > > You can load configuration > > > fromhttp://www.smalltalkhub.com/#!/~sig/TxText. Last version: 0.6. > > > See class side example methods. > > > > Impressive & cool ! > > > > But how do I actually run any of this code, apart from the tests ? > > > > I am not understrand what you want. All tests are runnable as usual from > > test runner or browser. > > I not wrote test which opens text morph on some text. Example class side > > methods should be executed manually > > I am sorry, I just can't find any class side example code in the Tx > packages/classes. Maybe I am looking in the wrong place. Can't you give an > actual class where I should look or an executable code snippet ? > > Sorry about it too. It was deep night when I push ann. > TxTextMorph has class side example methods to see how it can be used. Aah, I loaded the Tests group assuming that that would have loaded everything, but it didn't: I was missing the actual UI classes in TxtText-UI ! Now I found them, with class comments and examples: much better for a noob like me ;-) Sven
Re: [Pharo-project] Smart Suggestion Version 1
On Apr 26, 2013, at 4:41 PM, Gisela Decuzzi wrote: > > 2013/4/24 stephane ducasse > What would be cool is to have a way to select the enclosing expression but > you know it:) > > Now I'm selecting the node from the expression where you asked for > suggestions... I'm looking to for underline the scope but it's an advance. > > Also if you want to try it's working in Rubric text editor example (but only > throw the menu). I should look at it :)
Re: [Pharo-project] [Ann] TxText. New text editor done!
2013/4/27 Denis Kudriashov > 2013/4/27 Sven Van Caekenberghe > >> >> On 27 Apr 2013, at 10:02, Denis Kudriashov wrote: >> >> > Hi >> > >> > 2013/4/27 Sven Van Caekenberghe >> > Hi Denis, >> > >> > On 26 Apr 2013, at 23:19, Denis Kudriashov >> wrote: >> > >> > > I'm happy to announce that new text editor based on new text model >> done. You can load configuration fromhttp:// >> www.smalltalkhub.com/#!/~sig/TxText. Last version: 0.6. >> > > See class side example methods. >> > >> > Impressive & cool ! >> > >> > But how do I actually run any of this code, apart from the tests ? >> > >> > I am not understrand what you want. All tests are runnable as usual >> from test runner or browser. >> > I not wrote test which opens text morph on some text. Example class >> side methods should be executed manually >> >> I am sorry, I just can't find any class side example code in the Tx >> packages/classes. Maybe I am looking in the wrong place. Can't you give an >> actual class where I should look or an executable code snippet ? >> > > Sorry about it too. It was deep night when I push ann. > TxTextMorph has class side example methods to see how it can be used. > > This examples based on #newTextContents: method which clean current text model and insert new string to it. If you want to edit and show multy styled text you should create TxModel instance manuallly and put it to morph by #textModel: To see how create text models looks at TxModelTests > > >> >> Thx, >> >> Sven >> > >
Re: [Pharo-project] [Ann] TxText. New text editor done!
Nice! Denis did you see the benchs that doru tried to see if we can use Rubric? Because it is interesting to see if we can load and manipulate really large file. Now it would be good that alain releases Rubric with a stable version and check how to take advantage of the new TextMorph. Stef On Apr 26, 2013, at 11:19 PM, Denis Kudriashov wrote: > Hi guys. > > I'm happy to announce that new text editor based on new text model done. You > can load configuration from http://www.smalltalkhub.com/#!/~sig/TxText. Last > version: 0.6. > See class side example methods. > > What available now in TxTextMorph: > - cursor navigation with move left, right, down, up and mouse click > - text selection with move left, right, down, up and mouse movement > - editing by keyboard input > - text wrap > - #addCursor/#removeCursor > - #enableSelection. > - #beEditable > - all keyboard interractions based on shortcuts > > Little details about navigation and editing: > There is TxEditor object which know about cursor position and text selection. > Text morph ask him to perform all navigation and editing behaviour. > It has cursorMode which knows how to change editor selection when cursor > moved. Editor delegates all move actions to cursorPosition by > #doesNotUnderstand method. It is simplified adding new navigation methods. > For example see TxTextMorph>>enableSelection > > aTxTextMorph>>moveEditorOn: Character arrowLeft by: #moveLeft. > > This expression adds two shortcuts: to move editor left and to select text > left (when selectionModeModifier active). > > What next: > - Remains standart navigation and editing features like copy/paste, move to > line end, to text end and etc. > - halo menu items to edit text and layout properties > - Edit decorators to get mask behaviour like "(999)***-**-**", pretty numbers > like "1'000'000", secrete field like "***" > - Value specs to filter inserted text (only numbers, only english and etc) > > There are some problems with focus behaviour now. And drawing text morph with > transparent back color works bad. It will be cool if somebody with good > knowledge at this topics can fix it. > > Best regards, > Denis
Re: [Pharo-project] [update 3.0] #30066
On Apr 27, 2013, at 10:10 AM, stephane ducasse wrote: > marcus do you know why the diff does not work with SmalltalkHub? > No. > > On Apr 26, 2013, at 5:43 PM, Marcus Denker wrote: > >> 30066 >> - >> >> 10401 Add Amber BlockClosure asynchronous methods into Pharo >> https://pharo.fogbugz.com/f/cases/10401 >> >> 10418 cleanUp #methodHeaderFor: >> https://pharo.fogbugz.com/f/cases/10418 >> >> 10419 Remove CompiledMethodWithNode (part 2) >> https://pharo.fogbugz.com/f/cases/10419 >> >> Diff information: >> http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Traits-MarcusDenker.475 >> http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Tools-MarcusDenker.1083 >> http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Kernel-MarcusDenker.1382 >> http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Compiler-MarcusDenker.400 >> >> > >
Re: [Pharo-project] [Ann] TxText. New text editor done!
2013/4/27 Sven Van Caekenberghe > > On 27 Apr 2013, at 10:02, Denis Kudriashov wrote: > > > Hi > > > > 2013/4/27 Sven Van Caekenberghe > > Hi Denis, > > > > On 26 Apr 2013, at 23:19, Denis Kudriashov wrote: > > > > > I'm happy to announce that new text editor based on new text model > done. You can load configuration fromhttp:// > www.smalltalkhub.com/#!/~sig/TxText. Last version: 0.6. > > > See class side example methods. > > > > Impressive & cool ! > > > > But how do I actually run any of this code, apart from the tests ? > > > > I am not understrand what you want. All tests are runnable as usual from > test runner or browser. > > I not wrote test which opens text morph on some text. Example class side > methods should be executed manually > > I am sorry, I just can't find any class side example code in the Tx > packages/classes. Maybe I am looking in the wrong place. Can't you give an > actual class where I should look or an executable code snippet ? > Sorry about it too. It was deep night when I push ann. TxTextMorph has class side example methods to see how it can be used. > > Thx, > > Sven >
Re: [Pharo-project] [update 3.0] #30066
marcus do you know why the diff does not work with SmalltalkHub? On Apr 26, 2013, at 5:43 PM, Marcus Denker wrote: > 30066 > - > > 10401 Add Amber BlockClosure asynchronous methods into Pharo > https://pharo.fogbugz.com/f/cases/10401 > > 10418 cleanUp #methodHeaderFor: > https://pharo.fogbugz.com/f/cases/10418 > > 10419 Remove CompiledMethodWithNode (part 2) > https://pharo.fogbugz.com/f/cases/10419 > > Diff information: > http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Traits-MarcusDenker.475 > http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Tools-MarcusDenker.1083 > http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Kernel-MarcusDenker.1382 > http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Compiler-MarcusDenker.400 > >
Re: [Pharo-project] [Ann] TxText. New text editor done!
On 27 Apr 2013, at 10:02, Denis Kudriashov wrote: > Hi > > 2013/4/27 Sven Van Caekenberghe > Hi Denis, > > On 26 Apr 2013, at 23:19, Denis Kudriashov wrote: > > > I'm happy to announce that new text editor based on new text model done. > > You can load configuration fromhttp://www.smalltalkhub.com/#!/~sig/TxText. > > Last version: 0.6. > > See class side example methods. > > Impressive & cool ! > > But how do I actually run any of this code, apart from the tests ? > > I am not understrand what you want. All tests are runnable as usual from test > runner or browser. > I not wrote test which opens text morph on some text. Example class side > methods should be executed manually I am sorry, I just can't find any class side example code in the Tx packages/classes. Maybe I am looking in the wrong place. Can't you give an actual class where I should look or an executable code snippet ? Thx, Sven
Re: [Pharo-project] [Ann] TxText. New text editor done!
Hi 2013/4/27 Sven Van Caekenberghe > Hi Denis, > > On 26 Apr 2013, at 23:19, Denis Kudriashov wrote: > > > I'm happy to announce that new text editor based on new text model done. > You can load configuration fromhttp://www.smalltalkhub.com/#!/~sig/TxText. > Last version: 0.6. > > See class side example methods. > > Impressive & cool ! > > But how do I actually run any of this code, apart from the tests ? > I am not understrand what you want. All tests are runnable as usual from test runner or browser. I not wrote test which opens text morph on some text. Example class side methods should be executed manually > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > >
Re: [Pharo-project] more self documentation
Beautiful. If we are not careful, Pharo will look like a really hip & hot project ;-) On 27 Apr 2013, at 09:12, Camillo Bruni wrote: > I switched the listing template on the file-server to something smother > and started to add a bit more documentation about all the files there: > > http://updates.pharo.org/pharo3.0/
Re: [Pharo-project] [Ann] TxText. New text editor done!
Hi Denis, On 26 Apr 2013, at 23:19, Denis Kudriashov wrote: > I'm happy to announce that new text editor based on new text model done. You > can load configuration fromhttp://www.smalltalkhub.com/#!/~sig/TxText. Last > version: 0.6. > See class side example methods. Impressive & cool ! But how do I actually run any of this code, apart from the tests ? Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
[Pharo-project] more self documentation
I switched the listing template on the file-server to something smother and started to add a bit more documentation about all the files there: http://updates.pharo.org/pharo3.0/
