April White | 1 Jan 03:37
Picon
Favicon

Re: v1.67 version of my job implementation

Neil Hodgson wrote:

>>It is fixed; I decided to upload todays revisions under the same name as
>>above.
>>    
>>
>   OK. There are some threading worries. jobQueue.CurrentJob() returns
>a pointer to a single job object which could potentially be deleted
>while the pointer is being used even though currently this may be
>safe. Since nothing is written into this pointer, you could make the
>pointers const and also hand out a copy to ensure it can be used
>without worrying about deletion.
>
>  
>
I think I'll revise things again :-)

I'll remove 'CurrentJob()' and add 'CurrentJobFlags()' and 
'CurrentJobBufferPath()'
The two would be initialized within the CanExecute() code, returning 
copies of the respective values. 

I'll play with it while I'm waiting for New Years to arrive...

>   JobQueue::CurrentJobDirectory has a small vulnerability since it
>doesn't lock and copying a FilePath involves allocations. 
>  
>
I was about to say you were worrying to much, because the internal 
variable is only assigned within GetNextJob(), but I recalled that it is 
(Continue reading)

April White | 1 Jan 06:25
Picon
Favicon

Re: v1.67 version of my job implementation

April White wrote:

>> I think I'll revise things again :-)
>
> I'll remove 'CurrentJob()' and add 'CurrentJobFlags()' and 
> 'CurrentJobBufferPath()'
> The two would be initialized within the CanExecute() code, returning 
> copies of the respective values.
>
>>   JobQueue::CurrentJobDirectory has a small vulnerability since it
>> doesn't lock and copying a FilePath involves allocations.  
>
> I was about to say you were worrying to much, because the internal 
> variable is only assigned within GetNextJob(), but I recalled that it 
> is initialized within JobQueue::Clear(), so I agree that the variable 
> should be locked.  Additionally, since GetNextJob() is only called 
> from within CanExecute(), I've made it a private method

I've revised the code as above and uploaded it as 
http://www.scintilla.org/aprilw/scite-april-2005-12-31.zip

ttfn
April

--

-- 
Get a new car for your spouse. It'll be a great trade!
Philippe Lhoste | 1 Jan 15:41
Picon

Re: off the wall question

Megan Bock wrote:
> Oops. I've always said "site" too, because I assumed that Scintilla had 
> the soft "s" sound.

Well, I chose this pronunciation too... It is quite natural, easy for my 
tongue and less offensive than the sh... derivative :-)
And I think that SciTE doesn't any longer merits this depreciative 
connotation dating back from the times it was a "less-than-able" demo 
program for Scintilla.

So, Neil pronounces skintilla?
I always pronounced sintilla, probably because it is similar to the 
"scintiller" French verb, which even has a past form:
"L'étoile scintilla dans la nuit"
"The star twinkled in the night".

> On 12/29/05, *Robert Roessler* < robertr <at> rftp.com 
> <mailto:robertr <at> rftp.com>> wrote:
> 
>     Karl Anderson wrote:
>      > :What is the correct pronunciation of SciTE?
>      >
>      >
>      > Interesting :) Have I been mistaken calling it "sight" all this time?
>      > I personally prefer (sight/site)SciTe because it conveys a sense
>     of vision.
>      > By the way, I was delighted to see Komodo using Scintilla, it
>     made me feel very much at home.
>      >
>      >
(Continue reading)

Robert Roessler | 1 Jan 18:19
Favicon

Re: off the wall question

Philippe Lhoste wrote:
> ...
> So, Neil pronounces skintilla?
> I always pronounced sintilla, probably because it is similar to the 
> "scintiller" French verb, which even has a past form:
> "L'étoile scintilla dans la nuit"
> "The star twinkled in the night".
> 
>> On 12/29/05, *Robert Roessler* < robertr <at> rftp.com 
>> <mailto:robertr <at> rftp.com>> wrote:
>>  ...
>>     Gosh - I just always spell out the acronym when talking or thinking
>>     about it: S c i T E. :)
> 
> Wow, a bit tedious, and unnatural as you know that the Sci comes from 
> Scintilla, so there is no point to distinguish individual letters.

But it avoids any concerns about how it is supposed to sound! :)

The English verb is "scintillate", for emitting sparks or sparkling... 
both it and the noun "scintilla" are from the Latin verb "scintillare" 
("to sparkle") and noun "scintilla" ("spark").

BTW, in all of these, the "c" makes no contribution to the sound.

Robert Roessler
robertr <at> rftp.com
http://www.rftp.com
fk | 1 Jan 21:36
Picon

Bug ?

When editing a PHP file using the "heredoc" - method, Scte hangs under windows.
Jan Hendrik | 1 Jan 23:53
Picon

Re: off the wall question

Concerning Re: [scite] off the wall question
Philippe Lhoste wrote on 1 Jan 2006, 15:41, at least in part:

> Megan Bock wrote:
> > Oops. I've always said "site" too, because I assumed that Scintilla
> > had the soft "s" sound.
> 
> Well, I chose this pronunciation too... It is quite natural, easy for
> my tongue and less offensive than the sh... derivative :-) And I think
> that SciTE doesn't any longer merits this depreciative connotation
> dating back from the times it was a "less-than-able" demo program for
> Scintilla.
> 
> So, Neil pronounces skintilla?
> I always pronounced sintilla, probably because it is similar to the
> "scintiller" French verb, which even has a past form: "L'étoile
> scintilla dans la nuit" "The star twinkled in the night".

... and I always had Scylla and Charybdis on my mind!

Jan Hendrik

---------------------------------------
Freedom quote:

     Europe's elites will gain another victory over their people.
                -- The Times, London, Dec. 9, 2003,
                   on the - postponed - vote on a European constitution.
                   The German people will not be allowed to vote on it anyway.

(Continue reading)

Neil Hodgson | 2 Jan 01:25
Picon

Re: v1.67 version of my job implementation

April White:

> I was about to say you were worrying to much, because the internal
> variable is only assigned within GetNextJob(), but I recalled that it
> is initialized within JobQueue::Clear(), so I agree that the variable
> should be locked.

   Its also a matter of being defensive in case the code is changed in
the future. I am being pickier with your code than with other changes
to SciTE and even my own code for tool execution and thats because it
is threading code and also a consequence of having 2 sets of eyes
looking at it. My execute thread code would have been better if it had
seen more review.

> I've revised the code as above and uploaded it as
> http://www.scintilla.org/aprilw/scite-april-2005-12-31.zip

   Some minor edits for warnings:

..\src\JobQueue.cxx(128) : warning C4800: 'int' : forcing value to
bool 'true' or 'false' (performance warning)

	timeCommands = props.GetInt("time.commands") != 0;

SciTEWin.cxx(456) : error C2440: 'reinterpret_cast' : cannot convert
from 'LPARAM' to 'long'

   This one can be a static_cast as its just int to int.
reinterpret_cast is there for when you are being evil, turning ints
into pointers or similar, which is why there are 389 in Scintilla and
(Continue reading)

Neil Hodgson | 2 Jan 01:51
Picon

Re: off the wall question

Philippe Lhoste:

> So, Neil pronounces skintilla?

   No, I'm inconsistent here and don't pronounce the "c" as
"scintilla" is reasonably common English. Its often used in phrases
similar to "scintilla of evidence" used when arguing such as "but you
haven't produced one scintilla of evidence that global warming is
caused by multi-coloured clothing". This means searching for
"scintilla" returns lots of very boring arguments.

Jan Hendrik:

> ... and I always had Scylla and Charybdis on my mind!

   One of the contributions to using the name "Scintilla" was that I
grew up on Scylla Road (pronounced "silla" by us but according to a
friend who was into classic literature more accurately pronounced
"scalar") near Scylla Bay.
http://www.ausinspect.com.au/como.htm

   Neil
April White | 2 Jan 02:16
Picon
Favicon

Re: v1.67 version of my job implementation

Neil Hodgson wrote:

>	timeCommands = props.GetInt("time.commands") != 0;
>...
>	DWORD exitcode = static_cast<long>(lParam);
>  
>
You must be using a different compiler than MinGW, or something 
different.  These never complained when I compiled.  I've implemented 
them though.

>>I've also included in the zip file a new makefile ...
>>    
>>
>   There isn't really a folder above Scintilla and SciTE from a
>distribution point of view:
>  
>
I'll try to ensure that this file is not included in any future uploads.

I've also started to implement the interface between Lua and the new job 
system.  It may be rushing things, but it'll be in my next upload.

April

--

-- 
If everything seems to be going well, you have obviously overlooked something.
Neil Hodgson | 2 Jan 02:22
Picon

Re: v1.67 version of my job implementation

April White:

> You must be using a different compiler than MinGW, or something
> different.  These never complained when I compiled.  I've implemented
> them though.

   Yes, those warnings are from Microsoft VC++ which is what I mostly use.

   Neil

Gmane