Re: The Little Computer

Re: The Little Computer

[alin]

Hello.

I do not find it interesting to have written a compiler for C genrating
only x86/mips/etc code because if somebody asks "what happens behing the
X86 microcode ?" it is difficult to ask all questions.  As I did, I can
see the computer at all the levels.

On the other hand, I want to make a C compiler able to be modularized
such that I can specify the output, not only Hack, and this is
difficult.

I will make a first version starting in a few weeks now, but I will have
to polish it long time for it to be really good.  It is difficult to do
something good.

OK.  See you when I start doing it in December.  In the meantime it is
possible to spend a few hours to convert it to mit-scheme, but this is
not interesting, as it is too easy.

About the docs, as I said, we will talk in details and read carefully
your messages when the whole system is working.  It makes not too much
sense to talk about docs if the system is not completed.  Until then you
can program the litle computer only up to assembler level.

Now there is input/output available and this is great for testing it.



See you as soon as I restart working.


Alin






















Brandon Invergo <brandon@invergo.net> writes:

> Hi Alin,
>
> OK everything sounds fine from your update.  I'm glad we're on the same
> page now about the documentation.  I wasn't sure from your previous
> reply that you understood what I meant but I see now that you did
> understand, so apologies for hammering on about it.  In any case, good
> luck with the C compiler and let me know if you need any help/advice on
> anything with regards to the evaluation or GNU standards.
>
> Happy hacking,
> Brandon
>

-- 
No GNUs is bad news.

Re: as the accident occued... long lines in emacs buffers.

[Alin Soare]

Hi Emacs Devel.

I have just sent on emacs devel a message that was destinated elsewhere.

Because the accident occurred, I want to remember you that I intend to
solve the issue of long lines in emacs, by replacing the linear buffer
with red-black trees that keep the lines.

This will make emacs work incredible fast with long lines.

This supposes creating very specialized rbt, such that they are
optimized for emacs lines of the buffer.

As I said, I will not work alone for emacs on such a complex problem.
It would be a loss of time and stress.

I have all the prerequisite knowledge and experience to execute this
project, but I want to find a partner for him/her to read what I do and
to discuss it.

Next year I think I have time to work on this problem -- perhaps it
takes 2 months.

I am interested to execute it, as this bug makes me trouble in emacs all
the time (especially in buffers that have shell processes).

Starting from the next year I will live around Paris.  If somebody
around is interested to talk about this problem, please contact me.











 
-- 
No GNUs is bad news.

Re: as the accident occued... long lines in emacs buffers.

[David Kastrup]

Alin Soare <as1789@gmail.com> writes:

> Hi Emacs Devel.
>
> I have just sent on emacs devel a message that was destinated elsewhere.
>
> Because the accident occurred, I want to remember you that I intend to
> solve the issue of long lines in emacs, by replacing the linear buffer
> with red-black trees that keep the lines.
>
> This will make emacs work incredible fast with long lines.

I'll settle for "as fast as one would expect given its behavior on short
lines".  The negation of "incredibly slow" (which describes our current
behavior in some situations) is merely "credibly fast".

If you can get there in a useful and maintainable manner (which probably
means condensing the points of complexity to a confined part of the code
which can then explain its working with suitable comments), you'll
certainly gain the applause of a lot of users and developers.

-- 
David Kastrup

Re: as the accident occued... long lines in emacs buffers.

[David Kastrup]

David Kastrup <dak@gnu.org> writes:

> Alin Soare <as1789@gmail.com> writes:
>
>> Hi Emacs Devel.
>>
>> I have just sent on emacs devel a message that was destinated elsewhere.
>>
>> Because the accident occurred, I want to remember you that I intend to
>> solve the issue of long lines in emacs, by replacing the linear buffer
>> with red-black trees that keep the lines.
>>
>> This will make emacs work incredible fast with long lines.
>
> I'll settle for "as fast as one would expect given its behavior on short
> lines".

Though purportedly this should have been somewhat addressed by

cache-long-scans is a variable defined in ‘C source code’.
Its value is t

  Automatically becomes buffer-local when set.

Documentation:
Non-nil means that Emacs should use caches in attempt to speedup buffer scans.

There is no reason to set this to nil except for debugging purposes.

Normally, the line-motion functions work by scanning the buffer for
newlines.  Columnar operations (like ‘move-to-column’ and
‘compute-motion’) also work by scanning the buffer, summing character
widths as they go.  This works well for ordinary text, but if the
buffer’s lines are very long (say, more than 500 characters), these
motion functions will take longer to execute.  Emacs may also take
longer to update the display.

If ‘cache-long-scans’ is non-nil, these motion functions cache the
results of their scans, and consult the cache to avoid rescanning
regions of the buffer until the text is modified.  The caches are most
beneficial when they prevent the most searching---that is, when the
buffer contains long lines and large regions of characters with the
same, fixed screen width.

When ‘cache-long-scans’ is non-nil, processing short lines will
become slightly slower (because of the overhead of consulting the
cache), and the caches will use memory roughly proportional to the
number of newlines and characters whose screen width varies.

Bidirectional editing also requires buffer scans to find paragraph
separators.  If you have large paragraphs or no paragraph separators
at all, these scans may be slow.  If ‘cache-long-scans’ is non-nil,
results of these scans are cached.  This doesn’t help too much if
paragraphs are of the reasonable (few thousands of characters) size.

The caches require no explicit maintenance; their accuracy is
maintained internally by the Emacs primitives.  Enabling or disabling
the cache should not affect the behavior of any of the motion
functions; it should only affect their performance.

[back]

-- 
David Kastrup

Re: as the accident occued... long lines in emacs buffers.

[alin]

David Kastrup <dak@gnu.org> writes:

> Alin Soare <as1789@gmail.com> writes:
>
>> Hi Emacs Devel.
>>
>> I have just sent on emacs devel a message that was destinated elsewhere.
>>
>> Because the accident occurred, I want to remember you that I intend to
>> solve the issue of long lines in emacs, by replacing the linear buffer
>> with red-black trees that keep the lines.
>>
>> This will make emacs work incredible fast with long lines.
>
> I'll settle for "as fast as one would expect given its behavior on short
> lines".  The negation of "incredibly slow" (which describes our current
> behavior in some situations) is merely "credibly fast".
>
> If you can get there in a useful and maintainable manner (which probably
> means condensing the points of complexity to a confined part of the code
> which can then explain its working with suitable comments), you'll
> certainly gain the applause of a lot of users and developers.

I am not interested about applause in no way.

I am very interested about solving this -- I have a plan in my mind and
enough experience in math, C and emacs, but I need to talk with somebody
about this , as alone I cannot do it.

Do not hurry. During the spring I will come around Paris, and after a
while I will think considering this.

Starting from Sep-October 2017 I will be busy and have not too much time
for this for the next year.

If in the meantime somebody around is interested to read and discuss
about this just let me know.





Alin




-- 
No GNUs is bad news.

Re: as the accident occued... long lines in emacs buffers.

[alin]

David Kastrup <dak@gnu.org> writes:
 
>>> This will make emacs work incredible fast with long lines.
>>
>> I'll settle for "as fast as one would expect given its behavior on short
>> lines".
>
> Though purportedly this should have been somewhat addressed by
>
> cache-long-scans is a variable defined in ‘C source code’.
> Its value is t
>
>   Automatically becomes buffer-local when set.



I can guarantee Emacs with RBTs for line buffers will work with lines of
500K - 1M as fast as the current Emacs with lines of 100-200 bytes.






-- 
No GNUs is bad news.

Re: as the accident occued... long lines in emacs buffers.

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Fri, 13 Nov 2015 17:40:02 +0100
> Cc: John Wiegley <jwiegley@gmail.com>, Brandon Invergo <brandon@invergo.net>,
> 	emacs-devel@gnu.org
> 
> > I'll settle for "as fast as one would expect given its behavior on short
> > lines".
> 
> Though purportedly this should have been somewhat addressed by
> 
> cache-long-scans is a variable defined in ‘C source code’.
> Its value is t

No, this variable is unrelated.  It only helps when Emacs looks for a
newline.  By contrast, redisplay slowness with long lines has almost
nothing to do with searching a buffer for newlines, its main cause is
that to move to the next visual line the display engine must
completely traverse the current line.

Re: as the accident occued... long lines in emacs buffers.

[alin]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Fri, 13 Nov 2015 17:40:02 +0100
>> Cc: John Wiegley <jwiegley@gmail.com>, Brandon Invergo <brandon@invergo.net>,
>> 	emacs-devel@gnu.org
>> 
>> > I'll settle for "as fast as one would expect given its behavior on short
>> > lines".
>> 
>> Though purportedly this should have been somewhat addressed by
>> 
>> cache-long-scans is a variable defined in ‘C source code’.
>> Its value is t
>
> No, this variable is unrelated.  It only helps when Emacs looks for a
> newline.  By contrast, redisplay slowness with long lines has almost
> nothing to do with searching a buffer for newlines, its main cause is
> that to move to the next visual line the display engine must
> completely traverse the current line.

Anyway.  Emacs does not work well.  This is a fact that I see many times
when I open shell-processes.

I have the full plan in my mind to execute it.  And all the needed
experience and background.

I cannot work alone.  I need somebody to discuss with him/her and help
me read what I am doing and what's next step.  As this is a a complex
problem and I do not want to lose the time working.  This would be
painful to think to.

I think I will be available to do this in the months
Mars-Avr-May-June-July-Au. If somebody around Paris want to involve in
this, please answer me in the mean time.

If not, I will be available for this task after July 2018 or sporadic.
I think it will take 7-8 week-ends to execute it.  It will be lot of
work.





Alin.



-- 
No GNUs is bad news.

Re: as the accident occued... long lines in emacs buffers.

[alin]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Fri, 13 Nov 2015 17:40:02 +0100
>> Cc: John Wiegley <jwiegley@gmail.com>, Brandon Invergo <brandon@invergo.net>,
>> 	emacs-devel@gnu.org
>> 
>> > I'll settle for "as fast as one would expect given its behavior on short
>> > lines".
>> 
>> Though purportedly this should have been somewhat addressed by
>> 
>> cache-long-scans is a variable defined in ‘C source code’.
>> Its value is t
>
> No, this variable is unrelated.  It only helps when Emacs looks for a
> newline.  By contrast, redisplay slowness with long lines has almost
> nothing to do with searching a buffer for newlines, its main cause is
> that to move to the next visual line the display engine must
> completely traverse the current line.



Anyway.  Emacs does not work well.  This is a fact that I see many times
when I open shell-processes.

I have the full plan in my mind to execute it.  And all the needed
experience and background.

I cannot work alone.  I need somebody to discuss with him/her and help
me read/see what I am doing and what's the next step.  As this is a a
complex problem and I do not want to lose the time working.  This would
be painful to think to alone.

I think I will be available to do this in the months
Mars-Avr-May-June-July-Au. If somebody around Paris want to involve in
this, please answer me in the mean time.

If not, I will be available for this task after July 2018 or sporadic.
I think it will take 7-8 week-ends to execute it.  It will be lot of
work.





Alin.



-- 
No GNUs is bad news.