Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » U++ TheIDE » U++ TheIDE: Other Features Wishlist and/or Bugs » Very first impressions and.... [FEATURE REQUESTS]
Re: Very first impressions and.... [FEATURE REQUESTS] [message #11470 is a reply to message #11467] Fri, 14 September 2007 15:45 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 12124
Registered: November 2005
Ultimate Member
mdelfede wrote on Fri, 14 September 2007 06:44

uhhmmm... so I did misunderstand it. But I still think that it will be too complicated to account for previous headers changes when you cache the current one.



You do not need to do that. What you really need is to make the current macro set part of the "caching key" (together with header file path and time).

Mirek
Re: Very first impressions and.... [FEATURE REQUESTS] [message #11472 is a reply to message #11470] Fri, 14 September 2007 19:46 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1259
Registered: September 2007
Senior Contributor
luzr wrote on Fri, 14 September 2007 15:45



You do not need to do that. What you really need is to make the current macro set part of the "caching key" (together with header file path and time).



I see the point. But you must anyways rescan all headers coming after the changed or inserted one. Ok that'll be a rare occasion too.

Ciao

Max
Re: Very first impressions and.... [FEATURE REQUESTS] [message #11767 is a reply to message #11472] Tue, 25 September 2007 14:22 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 12124
Registered: November 2005
Ultimate Member
mdelfede wrote on Fri, 14 September 2007 13:46

luzr wrote on Fri, 14 September 2007 15:45



You do not need to do that. What you really need is to make the current macro set part of the "caching key" (together with header file path and time).



I see the point. But you must anyways rescan all headers coming after the changed or inserted one. Ok that'll be a rare occasion too.

Ciao

Max



Actually, maybe my working theory is wrong, but I think you do not have to rescan headers in this case, as long as the change in header does not change the macros...

Therefore this comes to quite simple scheme - each header has set of "input macros" as part of caching keys and produces a set of "output macros". As long as caching key matches, you can just take output macros of header instead of parsing it when you see #include.

Or that is the plan Smile If you see any flaw, do not stay silent, you would save my time following a wrong approach... Smile

(Well, the one possible flaw is that of course, some program constructs can start in one header and end in another. I decided simply to ignore this possibility for now...)

Mirek
Re: Very first impressions and.... [FEATURE REQUESTS] [message #11775 is a reply to message #11767] Tue, 25 September 2007 16:42 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1259
Registered: September 2007
Senior Contributor
luzr wrote on Tue, 25 September 2007 14:22


Actually, maybe my working theory is wrong, but I think you do not have to rescan headers in this case, as long as the change in header does not change the macros...



I don't think you're wrong, I only think all that is VERY complicated ! Razz

Quote:


Therefore this comes to quite simple scheme - each header has set of "input macros" as part of caching keys and produces a set of "output macros". As long as caching key matches, you can just take output macros of header instead of parsing it when you see #include.

Or that is the plan Smile If you see any flaw, do not stay silent, you would save my time following a wrong approach... Smile



No flaws at all, it seems all ok, but really complicated to code... If I did understand, you do that :
1 - On first scan, completely scan all headers
2 - Starting from first one (no input macros), you get 'output macros' from it and get some sort of hash or magic code from those macros.
3 - You repeat all that for following headers, storing the 'magic' on input and tha cached macros.
4 - On next scans, if first header is changed you rescan it and get again the 'magic code'
5 - if 'magic code' didn't change even if the header changed, you don't need to rescan following headers.

The only (small) flaw I see is that you change a macro on first header you must indeed rescan all following headers, but that's rare.

Quote:


(Well, the one possible flaw is that of course, some program constructs can start in one header and end in another. I decided simply to ignore this possibility for now...)


well, if a programmer does such a construct, he deserves the bad behaviour of parser.... I'd call it "just force things to make them buggy" Razz

What I don't see are 'big' advantages against a simpler (much simpler) background processing. Ok, you're real time each key you press, but your code will become very complicated and, in the (rare) possibility that user change a simple macro on first header, he will notice a long delay on editor.
OTOH, your way is of course more 'technical' and 'funny' to code...

Ciao

Max

p.s. do you think also to make some sort of word completion (besides member function/variables) ? Something like "type-2-chars-press-a-key-and-get-a-list-of-words" ? That would be useful too...
Re: Very first impressions and.... [FEATURE REQUESTS] [message #11782 is a reply to message #11775] Tue, 25 September 2007 18:22 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 12124
Registered: November 2005
Ultimate Member
mdelfede wrote on Tue, 25 September 2007 10:42

luzr wrote on Tue, 25 September 2007 14:22


Actually, maybe my working theory is wrong, but I think you do not have to rescan headers in this case, as long as the change in header does not change the macros...



I don't think you're wrong, I only think all that is VERY complicated ! Razz



Why? Well, there are some complicated details, but I think the basic principle is simple...


Quote:


The only (small) flaw I see is that you change a macro on first header you must indeed rescan all following headers, but that's rare.



Yes, but there is no other way...

Quote:


What I don't see are 'big' advantages against a simpler (much simpler) background processing.



Bacgkground processing really is not possible, I have shown you before. You do not know when it is supposed to stop. You cannot get a list of macros from preprocessor so that you can continue.

Quote:


p.s. do you think also to make some sort of word completion (besides member function/variables) ? Something like "type-2-chars-press-a-key-and-get-a-list-of-words" ? That would be useful too...



That is already there, ctrl+,

Mirek
Re: Very first impressions and.... [FEATURE REQUESTS] [message #11784 is a reply to message #11782] Tue, 25 September 2007 20:02 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1259
Registered: September 2007
Senior Contributor
luzr wrote on Tue, 25 September 2007 18:22


Bacgkground processing really is not possible, I have shown you before. You do not know when it is supposed to stop. You cannot get a list of macros from preprocessor so that you can continue.



Why ? Doing it in background you don't have to stop. You can (if you want) keep parsing the file and includes in background and switch from 2 contexts on the fly... All you can notice with this way is an outdated context between 2 parse cycles but, if you don't type (and think) at light speed, that would be unnoticeable.

Just an example of what can happen :
1) you start with this file :

#include <stdio.h>

int dosomething(int a, int b)
{
return a*b;
}

main()
{
dosomething( <-- CODE COMPLETION HERE)

}

After the first (background) scan, that works. Now, let add an include file 'inc.h' :

#define dosomething(x) (x)+2

So, you add an include in your file :

#include <stdio.h>

int dosomething(int a, int b)
{
return a*b;
}

#include "inc.h"

main()
{
dosomething( <-- CODE COMPLETION HERE)

}

There are 2 possibilities :

a- when you're typing 'dosomething(' you've got the old context, because the new one is not ready, so you get the wrong completion. But parse times should be matter of 2-3 seconds, so it's a rare event! the time you change add the include line and move the cursor, parser usually does ts work.

b- the new parsed context is ready, the ide switches to it, and you'll get the correct completion.

I really don't see what can be wrong.... you don't have to cache macros, don't have to worry about changes of macros in includes... All you need is to continue parsing the source (and its includes) in background.

The only pitfall is to double the memory to keep 2 contexts and some cpu time lost on background parses but, for an ide those are minor problems.

ah, if you meant that you can't use CPP, you're right, I was wrong, you can't use it for macros.

Quote:


That is already there, ctrl+,



..... I keep learning new stuffs each day... Smile
Thanx for the hint!

Ciao

Max
Re: Very first impressions and.... [FEATURE REQUESTS] [message #11787 is a reply to message #11784] Tue, 25 September 2007 23:01 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 12124
Registered: November 2005
Ultimate Member
mdelfede wrote on Tue, 25 September 2007 14:02

luzr wrote on Tue, 25 September 2007 18:22


Bacgkground processing really is not possible, I have shown you before. You do not know when it is supposed to stop. You cannot get a list of macros from preprocessor so that you can continue.



Why ? Doing it in background you don't have to stop. You can (if you want) keep parsing the file and includes in background and switch from 2 contexts on the fly... All you can notice with this way is an outdated context between 2 parse cycles but, if you don't type (and think) at light speed, that would be unnoticeable.

Just an example of what can happen :
1) you start with this file :

#include <stdio.h>

int dosomething(int a, int b)
{
return a*b;
}

main()
{
dosomething( <-- CODE COMPLETION HERE)

}

After the first (background) scan, that works.



OK, stop right there.

How does background scan know where is your cursor?

Mirek
Re: Very first impressions and.... [FEATURE REQUESTS] [message #11790 is a reply to message #11787] Tue, 25 September 2007 23:59 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1259
Registered: September 2007
Senior Contributor
luzr wrote on Tue, 25 September 2007 23:01



OK, stop right there.

How does background scan know where is your cursor?




He could know, but it isn't necessary.
He could know where the cursor is when you start the background scan... no problem. But for what ? When you store the parse context, you only add line numbers on scanned data, that's all.
When you look for completion, you look ONLY on scanned data that ha s line number BEFORE the current one.

Ciao

Max
Re: Very first impressions and.... [FEATURE REQUESTS] [message #11793 is a reply to message #11790] Wed, 26 September 2007 00:24 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 12124
Registered: November 2005
Ultimate Member
mdelfede wrote on Tue, 25 September 2007 17:59

luzr wrote on Tue, 25 September 2007 23:01



OK, stop right there.

How does background scan know where is your cursor?




He could know, but it isn't necessary.
He could know where the cursor is when you start the background scan... no problem. But for what ? When you store the parse context



Ah, I see. You plan to store parse context for all lines. OK, that would work to some degree... Would be pretty unreliable for fast typers, but yes, not entirely insane.

Just for the record, current (and future) parser does not work this way. In fact, a pretty bad trick is used - the file is "ended" at the position of cursor and parser fails on "unexpected end of file" error, which is in fact expect behaviour Smile Then the context is simply read from the parser. As simple as that:)

Mirek
Re: Very first impressions and.... [FEATURE REQUESTS] [message #11800 is a reply to message #11793] Wed, 26 September 2007 10:17 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1259
Registered: September 2007
Senior Contributor
luzr wrote on Wed, 26 September 2007 00:24



Ah, I see. You plan to store parse context for all lines.


Not exactly, I'd store the parse context for all definitions, quite less amount of data.

Quote:


OK, that would work to some degree... Would be pretty unreliable for fast typers, but yes, not entirely insane.



Well, if you find a programmer that is so fast typing to overcome the speed of a well done background parser, please send him to me, I've got some job for him Very Happy

Quote:



Just for the record, current (and future) parser does not work this way. In fact, a pretty bad trick is used - the file is "ended" at the position of cursor and parser fails on "unexpected end of file" error, which is in fact expect behaviour Smile Then the context is simply read from the parser. As simple as that:)



I understand this, but then you MUST do it in real time.
From my point of view, all you need is a data structure storing the function-classes-macro-ecc definitions along with line numbers where they're defined.
You keep 2 such structures, and swap them when the background task is done, an so forth.That's all. Then, all what you need to do in real time is to do a fast lookup in that data structure to find what you're typing. Quite simple and quick job, if data structure is well indexed.... much faster than to call the parser for each keypress and wait for him do complete the job.
BTW, the 'speed feeling' of users would be higher of an order of magnitude than full real-time approaches.

Well, again I've got no time to make some experiments with this idea... pity, because I find it promising.

Ciao

Max

p.s. The ctrl+ doesn't work for me.... do I miss something ?
Re: Very first impressions and.... [FEATURE REQUESTS] [message #11808 is a reply to message #11800] Wed, 26 September 2007 14:30 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 12124
Registered: November 2005
Ultimate Member
mdelfede wrote on Wed, 26 September 2007 04:17

luzr wrote on Wed, 26 September 2007 00:24



Ah, I see. You plan to store parse context for all lines.


Not exactly, I'd store the parse context for all definitions, quite less amount of data.

Quote:


OK, that would work to some degree... Would be pretty unreliable for fast typers, but yes, not entirely insane.



Well, if you find a programmer that is so fast typing to overcome the speed of a well done background parser, please send him to me, I've got some job for him Very Happy



He does not need to type that much fast to get false result. And the full parsing can take up to seconds.

Quote:


I understand this, but then you MUST do it in real time.
From my point of view, all you need is a data structure storing the function-classes-macro-ecc definitions along with line numbers where they're defined.



Not enough. You need to know in what function you are too and to have all local variables info. In fact, knowing in what expression and perhaps even statement you are is quite important too.

Quote:


You keep 2 such structures, and swap them when the background task is done, an so forth.



Hehe, sounds as seductive as all bad ideas in programming:)

Quote:


That's all. Then, all what you need to do in real time is to do a fast lookup in that data structure to find what you're typing.



Well, that is not enough. The more important is to find the context WHERE YOU ARE. In what method, what locals are currently defined.

Quote:


Quite simple and quick job, if data structure is well indexed.... much faster than to call the parser for each keypress and wait for him do complete the job.
BTW, the 'speed feeling' of users would be higher of an order of magnitude than full real-time approaches.



Well, do you feel that it is slow now?! What I am up to will be as fast...

Quote:


p.s. The ctrl+ doesn't work for me.... do I miss something ?



Ctrl+, - i mean key with comma... I mean, hold Ctrl and press comma key Wink

Mirek

[Updated on: Wed, 26 September 2007 14:31]

Report message to a moderator

Re: Very first impressions and.... [FEATURE REQUESTS] [message #11814 is a reply to message #11808] Wed, 26 September 2007 16:59 Go to previous message
mdelfede is currently offline  mdelfede
Messages: 1259
Registered: September 2007
Senior Contributor
luzr wrote on Wed, 26 September 2007 14:30



Hehe, sounds as seductive as all bad ideas in programming:)



tsk !!! That's only 'cause I've got no time to try it... Smile

Quote:



Well, that is not enough. The more important is to find the context WHERE YOU ARE. In what method, what locals are currently defined.



That's solved storing start-and-end lines of parsed context.

Quote:


Well, do you feel that it is slow now?! What I am up to will be as fast...


nope, I feel it VERY fast, NOW ! What I'm afraid about is that'll be no such fast AFTER !!! There's too much you want to add to your completion, and all that requires cpu time !

Quote:


Ctrl+, - i mean key with comma... I mean, hold Ctrl and press comma key Wink



Ahhhhh ! I didn't notice the ',' !!!! I'll try it this night !

Well, I can't wait to see your results !

Ciao

Max
Previous Topic: Escaped backslash in string confuse editor [bug]
Next Topic: Strange behaviour of the query option of TheIDE
Goto Forum:
  


Current Time: Fri Dec 13 14:53:20 CET 2019

Total time taken to generate the page: 0.02620 seconds