Re: Why I believe that using class based prototyping is suboptimal

2017-12-18 Thread Edward K. Ream 
On Monday, December 18, 2017 at 7:57:34 AM UTC-6, Edward K. Ream wrote:

Heh.  This is likely a colorizer performance bug, arising from the large 
number of section references in the top-level node. I have just opened #639: 
Colorizer is very slow when a node has thousands of section references 


The recursive import script reports: imported 2279 nodes in 1 file in 16.67 
seconds

Selecting the top-level imported node hangs for about 16 seconds. 

Adding @killcolor allows Leo to select the node after a delay of about 1/4 
seconds.

An @button node reporting c.p.numberOfChildren() says the node has 1394 
children.

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Why I believe that using class based prototyping is suboptimal

2017-12-18 Thread Edward K. Ream 
On Monday, December 18, 2017 at 7:46:09 AM UTC-6, Mike Hodson wrote:

Thanks.  I've got the files now.

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Why I believe that using class based prototyping is suboptimal

2017-12-18 Thread Edward K. Ream 
On Mon, Dec 18, 2017 at 6:22 AM, vitalije  wrote:

>
>
>
> Just tested the link, about 150k  for me ?!
>

​Still zero for me.

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Why I believe that using class based prototyping is suboptimal

2017-12-18 Thread vitalije 


On Monday, December 18, 2017 at 12:51:11 PM UTC+1, Edward K. Ream wrote:
>
> On Monday, December 18, 2017 at 5:19:10 AM UTC-6, vitalije wrote:
>>
>>
>> JavaScript files are here 
>>
>
> The .zip files has zero bytes.
>
> Edward
>
Just tested the link, about 150k  for me ?! Screenshoot attached.

Files are ordinary JavaScript source files not minimized. 
Here is beginning of rpg_objects.js
//=
// rpg_objects.js v1.3.0
//=

//-
// Game_Temp
//
// The game object class for temporary data that is not included in save 
data.

function Game_Temp() {
this.initialize.apply(this, arguments);
}

Game_Temp.prototype.initialize = function() {
this._isPlaytest = Utils.isOptionValid('test');
this._commonEventId = 0;
this._destinationX = null;
this._destinationY = null;
};

Game_Temp.prototype.isPlaytest = function() {
return this._isPlaytest;
};

Game_Temp.prototype.reserveCommonEvent = function(commonEventId) {
this._commonEventId = commonEventId;
};

Game_Temp.prototype.clearCommonEvent = function() {
this._commonEventId = 0;
};

Game_Temp.prototype.isCommonEventReserved = function() {
return this._commonEventId > 0;
};
...


-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Why I believe that using class based prototyping is suboptimal

2017-12-18 Thread Edward K. Ream 
On Mon, Dec 18, 2017 at 5:51 AM, Edward K. Ream  wrote:

> On Monday, December 18, 2017 at 5:19:10 AM UTC-6, vitalije wrote:
>>
>>
>> JavaScript files are here 
>>
>
> The .zip files has zero bytes.
>

​Leo's js importer might choke on big, compressed files without line
breaks.  Try pretty-printing the file first.

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Why I believe that using class based prototyping is suboptimal

2017-12-18 Thread Edward K. Ream 
On Monday, December 18, 2017 at 5:19:10 AM UTC-6, vitalije wrote:
>
>
> JavaScript files are here 
>

The .zip files has zero bytes.

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Why I believe that using class based prototyping is suboptimal

2017-12-18 Thread vitalije 


Do these problems still exist? If so, please send me the file.
>

Here is test code:
import timeit
fileName = '/tmp/rpg_objects.js'
p1 = p.insertAfter()
p1.h = '@auto ' + fileName
def doit():
c.importCommands.createOutline(fileName, parent=p1.copy())
t = timeit.timeit(doit, number=1)
p1.doDelete(p)
g.es('ok', t, 's')
c.redraw()


When invoked on my machine it shows about 30s is needed for one import. 
When I first tried to manually insert node with '@auto /tmp/rpg_objects.js' 
and execute command 'read-at-auto-nodes' it took more than a minute.

JavaScript files are here 
Vitalije
 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Why I believe that using class based prototyping is suboptimal

2017-12-18 Thread Edward K. Ream 
On Saturday, December 16, 2017 at 4:05:58 PM UTC-6, vitalije wrote:

> In April 2017, Edward wrote about [importer problems] on this forum and I 
decided to look into it.

> When I tried to import one javascript file, on my greatest surprise, Leo 
was blocked more than a minute. 

That's surprising. The present code should process each line only once.

Do these problems still exist? If so, please send me the file.

Leo's javascript importer consists of only two overrides of the linescanner 
base classes. js_i.scan_line is a line scanner that attempts to handle 
javascript's mind-bogglingly stupid *token* handling.

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Why I believe that using class based prototyping is suboptimal

2017-12-17 Thread Edward K. Ream 
On Sat, Dec 16, 2017 at 4:05 PM, vitalije  wrote:

> As I promised in other thread few days ago, that I will write in more
> detail about what I believe to be a better way to make prototype, I am glad
> to report that text is on the web.
>

​Not the best time for me to read or respond directly. I need a break from
this week's intense work. Both my thumbs are sore, but not too sore to
summarize from what I have done.

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Why I believe that using class based prototyping is suboptimal

2017-12-17 Thread Offray Vladimir Luna Cárdenas 
Hi,

Thanks for your post.


On 17/12/17 08:44, vitalije wrote:
>
> I read all three parts and found it interesting, although it wasn't
>
>  Thank you very much for your effort and feedback.
>
>
> So I guess after reading both pieces I get your point more - avoid
> constructing complex state to manage something that is essentially a
> process.  At least I think that's what your saying :)
>
>  Yes, that's what I wished to say.
>

This conversation remembers me Programming Across Paradigms, by Anjana
Vakil:

https://www.youtube.com/watch?v=Pg3UeB-5FdA

Now that functional programming is getting a new impulse, is interesting
to see the continuum that this talk is proposing. Dealing with global
state and a lot of intertwine in a mechanical clockwork alike fashion
makes development complicated. Functional and Objects keeps state
confined, the first in more aggressive way (i.e only in particular IO
monad) and the second by keeping it inside small objects that
communicate only through messages that makes easy to reason about state
(at least in the Pharo/Smalltalk case). Its interesting how the talk
invites us to use the proper paradigm to think about the problem,
instead of looking everything from the same paradigm and force the
problem to fit it, that I think shared Vitalije idea of avoiding complex
state to model what is essentially a process (a core proposal of
functional programming and the metaphor of the assembly line used by
Anjana and Richard Hickey).

In my case, despite of using exclusively Pharo now for my
programming/modeling, I try to get as much inspiration as I can from
other communities and paradigms (indie video gamers, clojure, music live
coding, this community). I think that this broader panoramic and
experience improves my coding, even despite of happening only inside
Pharo, so thanks Vitalije and Terry for the talk :-).

Cheers,

Offray

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Why I believe that using class based prototyping is suboptimal

2017-12-17 Thread Terry Brown 
On Sun, 17 Dec 2017 05:44:34 -0800 (PST)
vitalije  wrote:

> I agree, contrasting code examples would show more. I was feeling
> uneasy about criticizing Leo's code base too explicitly. 

I'm not sure if Leo is the best example to make the comparison, a more
self contained example might make the comparison accessible for a
larger audience.

> However, I feel that I need some tool for documenting process. There
> are lot of screen recording tools, but I want something more specific.

Leo has a slide show / demo functionality, and also
screen-capture-now and screen-capture-5sec, which screen cap. the Leo
window to .leo/screen_captures.  There's no feedback, seeing
they assume you don't want "Image saved
to /home/tbrown/.leo/screen_captures/2017-12-17T09-40-53.png" visible
in the log in your example images.  The 5sec version fires after 5
seconds, so you can open menus etc.

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Why I believe that using class based prototyping is suboptimal

2017-12-17 Thread vitalije 

>
> I read all three parts and found it interesting, although it wasn't 
>
 Thank you very much for your effort and feedback.

>
> So I guess after reading both pieces I get your point more - avoid 
> constructing complex state to manage something that is essentially a 
> process.  At least I think that's what your saying :)

 Yes, that's what I wished to say.

 Perhaps the 
> example would help more if there was more contrasting between one 
> approach and another, with only one solution explored there's less of a 
> feeling for the comparison being made. 
>

I agree, contrasting code examples would show more. I was feeling uneasy 
about criticizing Leo's code base too explicitly. I was afraid that it may 
sound offensive and that was not my intention. So, I decided to just tell 
how I feel when reading such code, explaining about what might be found 
there and left the readers to look into code if they want and see for 
themselves. 

I am tempted to go right now to hunt this bug and write about my journey 
there. That may show in more contrast code examples and make my previous 
post clearer.

However, I feel that I need some tool for documenting process. There are 
lot of screen recording tools, but I want something more specific. I have 
an idea how to make Leo record my work and later make video or slide show 
and record voice explanations. I will work on prototype of such tool next 
few days and if I made something useful, I will
use it to make bug hunting video/slide show. In any case I will report here 
when ready.

Thanks again for your feedback.
Vitalije

PS: blog doesn't support comments yet. It is brand new, domain is 
registered on Friday and on Saturday evening it was launched. Hopefully, 
comments will be enabled soon, and until then this forum is place for 
discussion.

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Why I believe that using class based prototyping is suboptimal

2017-12-16 Thread Terry Brown 
On Sat, 16 Dec 2017 14:05:58 -0800 (PST)
vitalije  wrote:

> How I did it? You can read it here:
> http://computingart.net/functional-programming-for-prototyping.html
> 
> All comments are welcome.

You're blog doesn't support comments ;-)

I read all three parts and found it interesting, although it wasn't
until I read

https://docs.python.org/3/howto/functional.html

particularly

https://docs.python.org/3/howto/functional.html#modularity and
following that I felt I really start to understand the distinction
between functional programming and other styles.

I think it's confusing (to people with no prior introduction to
functional programming) when the python.org article, for example, says
that functional programming is the opposite of object oriented
programming.  That's partly perhaps because OOP is vaguely defined
most of the time.  It's classes and inheritance, and instantiation of
objects, and method resolution, and in some schools message passing.
But a class may just be a way of managing a set of related functional
functions.

So I guess after reading both pieces I get your point more - avoid
constructing complex state to manage something that is essentially a
process.  At least I think that's what your saying :)  Perhaps the
example would help more if there was more contrasting between one
approach and another, with only one solution explored there's less of a
feeling for the comparison being made.

Interesting, thanks.

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Why I believe that using class based prototyping is suboptimal

2017-12-16 Thread 'tfer' via leo-editor 
Hi,

The unresponsiveness after load may have to do with the number of lines the 
current node contains.  As the editor for nodes is all written in python, 
it has problems when the number of lines in a node is large.

On Saturday, December 16, 2017 at 5:05:58 PM UTC-5, vitalije wrote:
>
> As I promised in other thread few days ago, that I will write in more 
> detail about what I believe to be a better way to make prototype, I am glad 
> to report that text is on the web.
>
> Text is not short and perhaps needs some spelling and grammar corrections. 
> I would appreciate all feedback that you fellows can give.
>
> I was looking for a theme, a suitable example to discuss and better 
> explain my point of view. Problem that I chose was Leo import commander. In 
> April 2017, Edward wrote about problem on this forum and I decided to look 
> into it. I was expecting to make some improvements in this code and while 
> doing so to explain each step. On my surprise I have discovered serious 
> problem in this code. I have never used import commands before (* maybe 
> once or twice I don't remember). When I tried them last time I wasn't 
> satisfied with the results of imports and I did imports by hand.
>
> When I tried to import one javascript file, on my greatest surprise, Leo 
> was blocked more than a minute. After import, for each keypress or mouse 
> click I had to wait for about 30s. I could hardly delete imported node. 
> There must be a bug somewhere in this code. Later I created script to 
> profile just bare import of file and it turned out that Leo needed 30s to 
> import this file. File is about 300k and 8000-9000 lines. Some, Python 
> files in Leo are similar size.
>
> After few hours I have made prototype of new import_file function that 
> imports same file on average in 250ms.
>
> How I did it? You can read it here:
> http://computingart.net/functional-programming-for-prototyping.html
>
> All comments are welcome.
> Vitalije
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Why I believe that using class based prototyping is suboptimal

2017-12-16 Thread vitalije 
As I promised in other thread few days ago, that I will write in more 
detail about what I believe to be a better way to make prototype, I am glad 
to report that text is on the web.

Text is not short and perhaps needs some spelling and grammar corrections. 
I would appreciate all feedback that you fellows can give.

I was looking for a theme, a suitable example to discuss and better explain 
my point of view. Problem that I chose was Leo import commander. In April 
2017, Edward wrote about problem on this forum and I decided to look into 
it. I was expecting to make some improvements in this code and while doing 
so to explain each step. On my surprise I have discovered serious problem 
in this code. I have never used import commands before (* maybe once or 
twice I don't remember). When I tried them last time I wasn't satisfied 
with the results of imports and I did imports by hand.

When I tried to import one javascript file, on my greatest surprise, Leo 
was blocked more than a minute. After import, for each keypress or mouse 
click I had to wait for about 30s. I could hardly delete imported node. 
There must be a bug somewhere in this code. Later I created script to 
profile just bare import of file and it turned out that Leo needed 30s to 
import this file. File is about 300k and 8000-9000 lines. Some, Python 
files in Leo are similar size.

After few hours I have made prototype of new import_file function that 
imports same file on average in 250ms.

How I did it? You can read it here:
http://computingart.net/functional-programming-for-prototyping.html

All comments are welcome.
Vitalije



-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.