I recall thinking about it long and hard, since it seemed very powerful.
However, I could not find a use for it yet. Personally, I'd hate to see it
go, even if I have never used it, but that's just me I guess.

Ronald Vogelaar
--
http://www.rovosoft.com


----- Original Message -----
From: "Theodore H. Smith" <delete@...>
To: <elfdata@yahoogroups.com>
Sent: Thursday, July 13, 2006 12:03 AM
Subject: Re: [elfdata] Did anyone ever use ElfDataTokenHandler?


>
> ElfDataTokenHandler lets you attach handlers to any object, not just
> a subclass of ElfDataParser.
>
> Great idea.... except that in practice I've never used it. In fact
> ElfDataParser itself is really stretching things, it's also a great
> idea that I rarely use, even if it is great for parsing XML. The
> token handler thing just seems an idea too far, I'm not sure it gives
> an advantage. I never used it, and I'm not sure anyone else did.
>
> At the very least it should simplify my documentation to remove it.
>
>> I'm actually not quite sure what you mean. Obviously, I'm using it
>> with the
>> ElfDataParser, but you're saying you're not gonna change that...
>> Are you
>> saying you want to remove the possibility to use
>> ElfDataTokenHandler without
>> the ElfDataParser?
>>

ElfDataTokenHandler lets you attach handlers to any object, not just
a subclass of ElfDataParser.

Great idea.... except that in practice I've never used it. In fact
ElfDataParser itself is really stretching things, it's also a great
idea that I rarely use, even if it is great for parsing XML. The
token handler thing just seems an idea too far, I'm not sure it gives
an advantage. I never used it, and I'm not sure anyone else did.

At the very least it should simplify my documentation to remove it.

> I'm actually not quite sure what you mean. Obviously, I'm using it
> with the
> ElfDataParser, but you're saying you're not gonna change that...
> Are you
> saying you want to remove the possibility to use
> ElfDataTokenHandler without
> the ElfDataParser?
>
> Ronald Vogelaar
> --
> http://www.rovosoft.com
>
> ----- Original Message -----
> From: "Theodore H. Smith" <delete@...>
> To: "ronald Vogelaar" <enter@...>; <elfdata@yahoogroups.com>
> Sent: Wednesday, July 12, 2006 6:11 PM
> Subject: [elfdata] Did anyone ever use ElfDataTokenHandler?
>
> > Hi people,
> >
> > I'm wondering if anyone ever used ElfDataTokenHandler. It sees a lot
> > of complexity for something that was only ever an idea, an idea that
> > turns out I didn't really need anyhow. I've never actually used
> > ElfDataTokenHandler.
> >
> > I'm thinking of removing it.
> >
> > ElfDataParser will remain unchanged, although I might allow better
> > typing of the context parameter passed to handlers. Right now the
> > context is always of type ElfDataParser.
> >
> > It would be nice to allow the user to specify subclasses, so that
> > that don't need to explicitly typecast, as I must currently do with
> > my TinyXML project.
> >
> > --
> > http://elfdata.com/plugin/
> >
> >
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
> > __________ NOD32 1.1655 (20060712) Information __________
> >
> > This message was checked by NOD32 antivirus system.
> > http://www.eset.com
> >
> >
>
>
>

--
http://elfdata.com/plugin/

I'm actually not quite sure what you mean. Obviously, I'm using it with the
ElfDataParser, but you're saying you're not gonna change that... Are you
saying you want to remove the possibility to use ElfDataTokenHandler without
the ElfDataParser?

Ronald Vogelaar
--
http://www.rovosoft.com

----- Original Message -----
From: "Theodore H. Smith" <delete@...>
To: "ronald Vogelaar" <enter@...>; <elfdata@yahoogroups.com>
Sent: Wednesday, July 12, 2006 6:11 PM
Subject: [elfdata] Did anyone ever use ElfDataTokenHandler?


> Hi people,
>
> I'm wondering if anyone ever used ElfDataTokenHandler. It sees a lot
> of complexity for something that was only ever an idea, an idea that
> turns out I didn't really need anyhow. I've never actually used
> ElfDataTokenHandler.
>
> I'm thinking of removing it.
>
> ElfDataParser will remain unchanged, although I might allow better
> typing of the context parameter passed to handlers. Right now the
> context is always of type ElfDataParser.
>
> It would be nice to allow the user to specify subclasses, so that
> that don't need to explicitly typecast, as I must currently do with
> my TinyXML project.
>
> --
> http://elfdata.com/plugin/
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
> __________ NOD32 1.1655 (20060712) Information __________
>
> This message was checked by NOD32 antivirus system.
> http://www.eset.com
>
>

Hi people,

I'm wondering if anyone ever used ElfDataTokenHandler. It sees a lot
of complexity for something that was only ever an idea, an idea that
turns out I didn't really need anyhow. I've never actually used
ElfDataTokenHandler.

I'm thinking of removing it.

ElfDataParser will remain unchanged, although I might allow better
typing of the context parameter passed to handlers. Right now the
context is always of type ElfDataParser.

It would be nice to allow the user to specify subclasses, so that
that don't need to explicitly typecast, as I must currently do with
my TinyXML project.

--
http://elfdata.com/plugin/

Hi Friends;

On behalf of javalive.com, I'd like to extend an invitation to
javalive forums.

This forum has been launched from India and I would request all you
friends to use the same and make it a bigger success than jguru.com
or javaworld.com .

In addition to a versatile forum, javalive.com offers complimentary
features such as news,Techno News, Java Articles ,headlines,
weblinks, Polls,java blogs, source codes, downloads, and much more.

Here is a link to the javalive.com web site, where you'll find many
on-line services and resources to help the java community:

http://www.javalive.com
I hope you'll consider visiting the javalive forums.

If I can be of further assistance, please do not hesitate to contact
me.

Sincerely,

Webmaster
javalive.com

OK, I finally figured out an altered version of Levenshtein, which is
compatible with Smith-Waterman.

This means I can now continue development on my fuzzy search
algorithms! In fact the altered version of Levenshtein is simpler
than I expected it to be, it's so simple, but slightly unintuitive in
it's implementation.

This should be fun! Completing my fuzzy search algorithm should be fun.

It's been a long time since I worked on this code, and it is the
hardest most complex piece of code I've ever worked on. Hopefully I
should get up to speed again however in no longer than a day.

What does this mean for ElfData users?

Well, if they are using ElfData to do biological processing, it means
you'll be able to use it for BLAST-like searches.

What if you aren't using it for biological processing, just English?
In that case, you'll be able to do fuzzy sentance similarity testing!
This quite exciting actually.

ElfData will now be able to tell that the sentance "hello fred this
is my frog", contains the same words as "hello this is my frog fred".

Basically, it'll be able to detect re-arranged words in a sentance.
It's quite powerful actually. Very cool stuff. Now I must get onto my
C++ coding!

--
http://elfdata.com/plugin/

> The full list of features is here: http://www.elfdata.com/plugin/
> technicalref/

Oh,

And a partial list of speed comparisons is here: http://
www.elfdata.com/plugin/showcase/TestResult/index.html

I'll be working on improving my ElfData Showcase app to make more
descriptive html web pages, soon.

ElfData v4.7 is out.

Main improvements:

* Now on all RB platforms! Win32, Linux, and Mac.
* Fixed the only bug that was found, which was a rare bug in
ElfData.DebugView.
* General speed and RAM efficiency improvements.
* ElfDataDictionary.Count as integer added.
* RingTree class added.
* And other small improvements.


Full release notes here: http://www.elfdata.com/plugin/beta.html
download from here: http://www.elfdata.com/plugin/elfdata.zip

For anyone unfamiliar with the ElfData plugin. The ElfData plugin is
a string processing library that can speed up your code to make it
very fast, and help you write simpler code that generates better
results. From multiple search and replace, to character set
operations, to simply making string appends very fast, to all sorts
of Unicode goodies. The full list of features is here: http://
www.elfdata.com/plugin/technicalref/

--
http://elfdata.com/plugin/

Well, I did a lot of things.

* The new leak tests are done. No leaks.
* Linux compiles with a nice makefile I copied and adapted.
* Fixed all the bugs I found to do with endianness on the PC version.
(No endian bugs were on the Mac version).
* A few more bug fixes.

I can't see any more bugs for Mac. And only 1 bug left for PC, in the
ElfData.Scan_Verify function.

Hopefully linux should run smoothly, as it is all data stuff I'm
doing, no platform APIs I'm calling or anything silly like that. I'll
get to that as soon as I fix the .Scan_Verify bug for PC.

--
http://elfdata.com/plugin/

What does our work achieve, if it's not making the world a happier
place?
http://www.whatnextjournal.co.uk/Pages/Next/Happiness.html
When's the last time you thought deeply about how to improve our lives?

Well, I've finally debugged my new ElfData plugin.

The last things to do are:

1) Write a leak testing framework for RB strings. This is one
oversight in my "industrial strength" doctrine that I over looked.
So... string leaks have to be tested for.

There is no way I can ask RB the number of strings in existance
unfortunately, so I'll just need to do it brute force in Mac OS
Classic, just call every function that takes or returns a string and
put it in a big loop.

2) Update documentation and website.

3) Compile & test my plugin for Linux, create the makefiles and all
that horrible stuff.

4) Compile the Mac version, integrate the Linux version into the Mac
version.

Great! Thanks!

Ronald Vogelaar
--
http://www.rovosoft.com

Theodore H. Smith wrote:

>Hi Ronald,
>
>Yes I did not include it, purposefully.
>
>Then I realised a few weeks ago this was the wrong decision :)
>
>It's already coded and tested for the next release.
>
>For the moment you can use an ElfData_Extensions module, to do the same.
>
>
>function Trim(Extends e as ElfData) As ElfData
> dim FirstLetter, LastLetter as integer
>
> FirstLetter = e.OutWhite
> if FirstLetter > 0 then
>  LastLetter = e.OutRevWhite
>  return e.Range( FirstLetter, LastLetter + 1 )
> end if
> return ED_Empty
>end function
>
>
>On 18 Nov 2005, at 11:43, Ronald Vogelaar wrote:
>
>
>
>>Hi Theo,
>>
>>One thing I just realised: There does not seem to be a Trim() (LTrim
>>(),
>>RTrim()) function for ElfData. I know this can easily be achieved, but
>>the same goes for RB's String DataType.
>>It seems somethat odd not to have this function in a string processing
>>library.
>>Did you not include it purposely?
>>
>>Ronald Vogelaar
>>--
>>http://www.rovosoft.com
>>
>>
>>------------------------ Yahoo! Groups Sponsor --------------------
>>~-->
>>Fair play? Video games influencing politics. Click and talk back!
>>http://us.click.yahoo.com/eMf55D/tzNLAA/TtwFAA/umvwlB/TM
>>--------------------------------------------------------------------
>>~->
>>
>>
>>Yahoo! Groups Links
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>--
>http://elfdata.com/plugin/
>
>What does our work achieve, if it's not making the world a happier
>place?
>http://www.whatnextjournal.co.uk/Pages/Next/Happiness.html
>When's the last time you thought deeply about how to improve our lives?
>
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>
>

Hi Ronald,

Yes I did not include it, purposefully.

Then I realised a few weeks ago this was the wrong decision :)

It's already coded and tested for the next release.

For the moment you can use an ElfData_Extensions module, to do the same.


function Trim(Extends e as ElfData) As ElfData
	 dim FirstLetter, LastLetter as integer

	 FirstLetter = e.OutWhite
	 if FirstLetter > 0 then
		 LastLetter = e.OutRevWhite
		 return e.Range( FirstLetter, LastLetter + 1 )
	 end if
	 return ED_Empty
end function


On 18 Nov 2005, at 11:43, Ronald Vogelaar wrote:

> Hi Theo,
>
> One thing I just realised: There does not seem to be a Trim() (LTrim
> (),
> RTrim()) function for ElfData. I know this can easily be achieved, but
> the same goes for RB's String DataType.
> It seems somethat odd not to have this function in a string processing
> library.
> Did you not include it purposely?
>
> Ronald Vogelaar
> --
> http://www.rovosoft.com
>
>
> ------------------------ Yahoo! Groups Sponsor --------------------
> ~-->
> Fair play? Video games influencing politics. Click and talk back!
> http://us.click.yahoo.com/eMf55D/tzNLAA/TtwFAA/umvwlB/TM
> --------------------------------------------------------------------
> ~->
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>


--
http://elfdata.com/plugin/

What does our work achieve, if it's not making the world a happier
place?
http://www.whatnextjournal.co.uk/Pages/Next/Happiness.html
When's the last time you thought deeply about how to improve our lives?

Hi Theo,

One thing I just realised: There does not seem to be a Trim() (LTrim(),
RTrim()) function for ElfData. I know this can easily be achieved, but
the same goes for RB's String DataType.
It seems somethat odd not to have this function in a string processing
library.
Did you not include it purposely?

Ronald Vogelaar
--
http://www.rovosoft.com

Theodore H. Smith wrote:

>It'll be just the same as doing fs1.AppendElfData fs2, though.
>
>If I were to implement it anyhow that's what I'd do internally, I'd
>write C code that does exactly that. I might even do it in one line
>of C, so I don't think it'll help.
>
>You might as well do fs1.AppendElfData fs2 yourself.
>
>
>
Oh okay, that's okay then. That's exactly what I wanted to know. I
wouldn't have used the AppendFastString right away anyways. My code has
become so incredibly compact over the past months that I'd be afraid to
introduce a bug that doesn't show immediately.
It's come to a stage where I doubt much speed (if any) can be gained
anymore. Unless it's rewritten in assembler, which I fersure won't be
doing ;-)

This is a good thing because it means I can focus on other stuff.

Ronald Vogelaar
--
http://www.rovosoft.com

It'll be just the same as doing fs1.AppendElfData fs2, though.

If I were to implement it anyhow that's what I'd do internally, I'd
write C code that does exactly that. I might even do it in one line
of C, so I don't think it'll help.

You might as well do fs1.AppendElfData fs2 yourself.



On 15 Nov 2005, at 13:14, Ronald Vogelaar wrote:

> I actually found more instances in my code where I could use the
> AppendFastString function... So, if you have no use for it
> otherwise and you would be inclined to change this function, you'd
> have at least one user that actually uses it <grins>
>
> If you wish to maintain current functionality, I wouldn't mind
> having to do:
> fs.AppendFastString fs2.GetResult(nil)
>
> ....but I guess that would not be the most logical solution...?
> Perhaps you could make it so that one could use:
> fs.AppendFastString fs2
> //fs2 is now empty
>
> Ronald Vogelaar
> --
> http://www.rovosoft.com
>
> Ronald Vogelaar wrote:
>> It's basically one method adding strings and elfdata into a
>> FastString that's calling another method that creates a relative
>> path from a destination path to the current file. Because it may
>> get called quite often, I thought I could gain a bit by not having
>> to do the intermediate emptying of one faststring, creating an
>> ElfData object, which gets added to another FastString. What
>> you're saying makes sense though... it's just that I apperently
>> have no use for AppendFastString (as it is). If you were to change
>> it so it clears the buffer of the faststring that's added, I could
>> use the function, but it's not a big deal. Ronald Vogelaar --
>> http://www.rovosoft.com Theodore H. Smith wrote:
>>> You can ask bugs on the ElfData yahoo group if you like :) I
>>> don't mind. But anyhow. It's designed to work that way. In fact I
>>> wonder sometimes why I added fs.AppendFastString. I think I added
>>> it simply because I was adding everything else. I'm not sure if
>>> anyone needs fs.AppendFastString or uses it. Basically, none of
>>> the append methods should change the thing they are appending.
>>> And it is possible to get access to FastString's internal buffer
>>> without clearing the FastString. Just call FastString.Buffer.
>>> This only returns the portion that was already written into, so
>>> you won't see any "live" data. I've managed this so that the
>>> immutability of the ElfData isn't comprimised without wasting RAM
>>> to copy the data. Just curious what are you
>>> using .AppendFastString for? On 15 Nov 2005, at 08:59, Ronald
>>> Vogelaar wrote:
>>>> Hi Theo, I just found out that this line fs1.AppendFastString
>>>> fs2 leaves fs2 (its contents) intact. This is bad when fs2 is a
>>>> global FastString (unless you'd want this behavior). I tried :
>>>> fs1.AppendFastString fs2.GetResult(nil) but that didn't work.
>>>> So, I'm either forced to use a local faststring, which I don't
>>>> want because of the penalty of doing that every time the method
>>>> is run, or use: fs1.AppendElfData fs2.GetResult(nil) ....in
>>>> which case you'd also lose. Is that how you'd expect
>>>> AppendFastString to work or is it a bug? It seems like a bug to
>>>> me since: dim t as string fs.AppendString "some string" t=fs
>>>> this does clear the faststring... And this too: dim ed as
>>>> ElfData ed="some string" fs.AppendElfData ed ed=fs And this too:
>>>> edf=new ElfDataFields(fs,10) ....but this is basically the same
>>>> as the previous example (ElfData). Ronald Vogelaar -- http://
>>>> www.rovosoft.com
>>> -- http://elfdata.com/plugin/ What does our work achieve, if it's
>>> not making the world a happier place? http://
>>> www.whatnextjournal.co.uk/Pages/Next/Happiness.html When's the
>>> last time you thought deeply about how to improve our lives?
>>> Yahoo! Groups Links
>> ------------------------ Yahoo! Groups Sponsor --------------------
>> ~--> Fair play? Video games influencing politics. Click and talk
>> back! http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/umvwlB/TM
>> --------------------------------------------------------------------~
>> this group, send an email to: elfdata-unsubscribe@yahoogroups.com
>
>
> YAHOO! GROUPS LINKS
>
>  Visit your group "elfdata" on the web.
>
>  To unsubscribe from this group, send an email to:
>  elfdata-unsubscribe@yahoogroups.com
>
>  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
>


--
http://elfdata.com/plugin/

What does our work achieve, if it's not making the world a happier
place?
http://www.whatnextjournal.co.uk/Pages/Next/Happiness.html
When's the last time you thought deeply about how to improve our lives?

On 15 Nov 2005, at 12:55, Ronald Vogelaar wrote:

> Hi Theo,
>
> Is there a logical reason why you named the function that appends an
> integer as a string to a FastString: 'AppendIntegerAsText', and not
> 'AppendIntegerAsString'?
>
> I mistype this virtually everytime I use it.

Because I was going to add an "AppendIntegerAsHex" function. Both hex
and text are strings.

Or maybe it was because I have a ElfData.TextInteger function, which
was different from the ElfData.HexInteger function. I couldn't have a
ElfData.StringInteger because what kind of string would it be?

I guess I just wanted to make .textInteger and .IntegerAstext be sort
of opposites.

I know it's confusing though because I have the words String and Text
in my plugin, and they usually mean the same thing.

To me, a string is just arbitrary data, it could be anything, even
binary code. Text is user readable text.


--
http://elfdata.com/plugin/

What does our work achieve, if it's not making the world a happier
place?
http://www.whatnextjournal.co.uk/Pages/Next/Happiness.html
When's the last time you thought deeply about how to improve our lives?

It's basically one method adding strings and elfdata into a FastString that's calling another method that creates a relative path from a destination path to the current file. Because it may get called quite often, I thought I could gain a bit by not having to do the intermediate emptying of one faststring, creating an ElfData object, which gets added to another FastString.
What you're saying makes sense though... it's just that I apperently have no use for AppendFastString (as it is). If you were to change it so it clears the buffer of the faststring that's added, I could use the function, but it's not a big deal.
Ronald Vogelaar
--
http://www.rovosoft.com
Theodore H. Smith wrote:

You can ask bugs on the ElfData yahoo group if you like :) I don't mind.
But anyhow.
It's designed to work that way. In fact I wonder sometimes why I added fs.AppendFastString. I think I added it simply because I was adding everything else. I'm not sure if anyone needs fs.AppendFastString or uses it.
Basically, none of the append methods should change the thing they are appending.
And it is possible to get access to FastString's internal buffer without clearing the FastString. Just call FastString.Buffer. This only returns the portion that was already written into, so you won't see any "live" data.
I've managed this so that the immutability of the ElfData isn't comprimised without wasting RAM to copy the data.
Just curious what are you using .AppendFastString for?
On 15 Nov 2005, at 08:59, Ronald Vogelaar wrote:

Hi Theo,
I just found out that this line
fs1.AppendFastString fs2
leaves fs2 (its contents) intact.
This is bad when fs2 is a global FastString (unless you'd want this behavior). I tried :
fs1.AppendFastString fs2.GetResult(nil)
but that didn't work. So, I'm either forced to use a local faststring, which I don't want because of the penalty of doing that every time the method is run, or use:
fs1.AppendElfData fs2.GetResult(nil)
...in which case you'd also lose. Is that how you'd expect AppendFastString to work or is it a bug? It seems like a bug to me since:
dim t as string
fs.AppendString "some string"
t=fs
this does clear the faststring...
And this too:
dim ed as ElfData
ed="some string"
fs.AppendElfData ed
ed=fs
And this too:
edf=new ElfDataFields(fs,10)
...but this is basically the same as the previous example (ElfData).
Ronald Vogelaar
--
http://www.rovosoft.com

--
http://elfdata.com/plugin/
What does our work achieve, if it's not making the world a happier place?
http://www.whatnextjournal.co.uk/Pages/Next/Happiness.html
When's the last time you thought deeply about how to improve our lives?
Yahoo! Groups Links

------------------------ Yahoo! Groups Sponsor --------------------~--> Fair play? Video games influencing politics. Click and talk back!
http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/umvwlB/TM
--------------------------------------------------------------------~-> Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/elfdata/
<*> To unsubscribe from this group, send an email to:
elfdata-unsubscribe@yahoogroups.com
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Hi Theo,

Is there a logical reason why you named the function that appends an
integer as a string to a FastString: 'AppendIntegerAsText', and not
'AppendIntegerAsString'?

I mistype this virtually everytime I use it.

Ronald Vogelaar
--
http://www.rovosoft.com

It's basically one method adding strings and elfdata into a FastString
that's calling another method that creates a relative path from a
destination path to the current file. Because it may get called quite
often, I thought I could gain a bit by not having to do the intermediate
emptying of one faststring, creating an ElfData object, which gets added
to another FastString.
What you're saying makes sense though... it's just that I apperently
have no use for AppendFastString (as it is). If you were to change it so
it clears the buffer of the faststring that's added, I could use the
function, but it's not a big deal.

Ronald Vogelaar
--
http://www.rovosoft.com


Theodore H. Smith wrote:

>
>You can ask bugs on the ElfData yahoo group if you like :) I don't mind.
>
>But anyhow.
>
>It's designed to work that way. In fact I wonder sometimes why I
>added fs.AppendFastString. I think I added it simply because I was
>adding everything else. I'm not sure if anyone needs
>fs.AppendFastString or uses it.
>
>Basically, none of the append methods should change the thing they
>are appending.
>
>And it is possible to get access to FastString's internal buffer
>without clearing the FastString. Just call FastString.Buffer. This
>only returns the portion that was already written into, so you won't
>see any "live" data.
>
>I've managed this so that the immutability of the ElfData isn't
>comprimised without wasting RAM to copy the data.
>
>Just curious what are you using .AppendFastString for?
>
>On 15 Nov 2005, at 08:59, Ronald Vogelaar wrote:
>
>
>
>>Hi Theo,
>>
>>I just found out that this line
>>
>>fs1.AppendFastString fs2
>>
>>leaves fs2 (its contents) intact.
>>
>>This is bad when fs2 is a global FastString (unless you'd want this
>>behavior). I tried :
>>fs1.AppendFastString fs2.GetResult(nil)
>>
>>but that didn't work. So, I'm either forced to use a local
>>faststring, which I don't want because of the penalty of doing that
>>every time the method is run, or use:
>>fs1.AppendElfData fs2.GetResult(nil)
>>
>>...in which case you'd also lose. Is that how you'd expect
>>AppendFastString to work or is it a bug? It seems like a bug to me
>>since:
>>dim t as string
>>fs.AppendString "some string"
>>t=fs
>>
>>this does clear the faststring...
>>And this too:
>>dim ed as ElfData
>>ed="some string"
>>fs.AppendElfData ed
>>ed=fs
>>
>>And this too:
>>edf=new ElfDataFields(fs,10)
>>
>>...but this is basically the same as the previous example (ElfData).
>>
>>Ronald Vogelaar
>>--
>>http://www.rovosoft.com
>>
>>
>>
>>
>
>
>--
>http://elfdata.com/plugin/
>
>What does our work achieve, if it's not making the world a happier
>place?
>http://www.whatnextjournal.co.uk/Pages/Next/Happiness.html
>When's the last time you thought deeply about how to improve our lives?
>
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>

You can ask bugs on the ElfData yahoo group if you like :) I don't mind.

But anyhow.

It's designed to work that way. In fact I wonder sometimes why I
added fs.AppendFastString. I think I added it simply because I was
adding everything else. I'm not sure if anyone needs
fs.AppendFastString or uses it.

Basically, none of the append methods should change the thing they
are appending.

And it is possible to get access to FastString's internal buffer
without clearing the FastString. Just call FastString.Buffer. This
only returns the portion that was already written into, so you won't
see any "live" data.

I've managed this so that the immutability of the ElfData isn't
comprimised without wasting RAM to copy the data.

Just curious what are you using .AppendFastString for?

On 15 Nov 2005, at 08:59, Ronald Vogelaar wrote:

> Hi Theo,
>
> I just found out that this line
>
> fs1.AppendFastString fs2
>
> leaves fs2 (its contents) intact.
>
> This is bad when fs2 is a global FastString (unless you'd want this
> behavior). I tried :
> fs1.AppendFastString fs2.GetResult(nil)
>
> but that didn't work. So, I'm either forced to use a local
> faststring, which I don't want because of the penalty of doing that
> every time the method is run, or use:
> fs1.AppendElfData fs2.GetResult(nil)
>
> ...in which case you'd also lose. Is that how you'd expect
> AppendFastString to work or is it a bug? It seems like a bug to me
> since:
> dim t as string
> fs.AppendString "some string"
> t=fs
>
> this does clear the faststring...
> And this too:
> dim ed as ElfData
> ed="some string"
> fs.AppendElfData ed
> ed=fs
>
> And this too:
> edf=new ElfDataFields(fs,10)
>
> ...but this is basically the same as the previous example (ElfData).
>
> Ronald Vogelaar
> --
> http://www.rovosoft.com
>
>


--
http://elfdata.com/plugin/

What does our work achieve, if it's not making the world a happier
place?
http://www.whatnextjournal.co.uk/Pages/Next/Happiness.html
When's the last time you thought deeply about how to improve our lives?

They are both equivalent in terms of operation.

I'd think that ed.mid(k) is better practice, simply because it's
simpler. Should you need to replace that with ed.range or ed.right,
you'll find it a lot easier to update your code.

On 15 Nov 2005, at 06:23, Ronald Vogelaar wrote:

> What would be considered better practice?:
>
> fs.AppendElfData ed.mid(k)
>
> or
>
> fs.AppendSectElfData ed, k, d.length
>
>
> Regards,
>
> Ronald Vogelaar
> --
> http://www.rovosoft.com
>
>
> ------------------------ Yahoo! Groups Sponsor --------------------
> ~-->
> Fair play? Video games influencing politics. Click and talk back!
> http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/umvwlB/TM
> --------------------------------------------------------------------
> ~->
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>


--
http://elfdata.com/plugin/

What does our work achieve, if it's not making the world a happier
place?
http://www.whatnextjournal.co.uk/Pages/Next/Happiness.html
When's the last time you thought deeply about how to improve our lives?

What would be considered better practice?:

fs.AppendElfData ed.mid(k)

or

fs.AppendSectElfData ed, k, d.length


Regards,

Ronald Vogelaar
--
http://www.rovosoft.com

No idea sorry.

It's just a hobby anyhow. These things need to be done properly and I
have no idea what properly means before the time comes that I must do
it :)

I don't think it could be more than 2 weeks away from a release, but
that's what I said 3 weeks ago... Still, this time I am certain
because I've done the majority of work.

Now I just need to do testing and minor changes.

I still need to:

1) Figure out how to add RB-like events, and code them.

2) Code C++'s operator overloading to implicitly do lock/unlock for
you. (Should be easy)

3) Create the typing system that can allow compile-time and run-time
type checking. Just a few smart #defines and let the C++ compiler do
most of the work for the compile-time checking. Run-time is harder
but not hard.

4) The nil object checking will be tightly integrated with the typing
system, so it's essentially the same job as number 3).

5) Test everything.


Mostly the design philosophy of the ElfData plugin for C++ is the
same as RB. Make it as easy as possible despite that it's actually an
internally complex library. So it must have char* operator converts
so that we can pass "strings" to any function that takes an ElfData,
must be RB-like when it comes to it's OOP memory management, and all
that sort of stuff.

I might write 3 demo projects for my C++ ElfData also. One just a
hello-world app. Another doing something intermediate like counting
words in a file. And another doing something advanced like writing a
well-formedness validating XML parser. I did the XML Parser in RB in
just 2 days so hopefully I can do the XML Parser for my "C OOP" in 2
days also :)


Really you are only missing a slightly faster plugin, and a RingTree
class. That's all the RB users get.


On 13 Nov 2005, at 19:01, Ronald Vogelaar wrote:

> Hi Theo,
>
> Sounds exciting! Sounds like an awful lot of work too! Any idea when
> it'll be ready?
>
> Ronald Vogelaar
> --
> http://www.rovosoft.com
>
> Theodore H. Smith wrote:
>
>>
>> I should probably make an update right about now.
>>
>> For the past few weeks I've been working on porting the ElfData
>> plugin to C.
>>
>> It might sound like a strange thing to say "porting the ElfData
>> plugin to C"... seeing as the ElfData plugin is *written* in C. But
>> it still is work, a lot of work.
>>
>> C and C++ have no concept of objects (or refcounted objects for C++'s
>> case). REALbasic does everything by refcounted objects. It's not so
>> simple as just allocating structs with malloc and filling the data in
>> them.
>>
>> How do you do REALUnlockObject upon an malloced void*??
>>
>> And what about nil object checking and type checking?
>>
>> What do do about all the functions that take and receive "string".
>> You can't REALLockString upon a char* can you?
>>
>> There are huge architectural differences between REALbasic's
>> environment and C.
>>
>> So what I've done is totally done away with REALbasic's plugin SDK.
>> Instead I now am using my own "ObjectPlatform" as I've named it.
>> ObjectPlatform is just a C/C++ API that lets you do proper object
>> oriented stuff, using refcounted objects, type checking, nil object
>> checking, in C.
>>
>> And it lets these objects you've created be accessable from C, or RB.
>> The way I've made ObjectPlatform it should be possible to make the
>> ElfData plugin work in Java also!
>>
>> However, most of the work I've had to do was to do with cleaning up
>> my code and modernising it a little. So much work there. Mostly I was
>> standardising my function names. Now I am using a convention I made
>> up that goes like this. Domain_Class_Function. So for ElfData's MSR's
>> Add function, you'd get ED_MSR_Add. This is because I hope my plugin
>> to be used in many C/C++ projects, and it absolutely needs
>> namespacing to keep it safe from name conflicts. ALso the
>> standardising helps to make it easier on the eyes and easier to
>> understand and remember.
>>
>> I've also had to spend great thought on scope. Some functions should
>> just NOT be called by ElfData users, but only by internal classes.
>> For this reason I've had to move a lot of function declarations from
>> the .h files into the .cpp files, or even into private .h files which
>> no ElfData user may include.
>>
>> In addition, I've made all the C functions have the same function
>> name as the RB functions!
>>
>> Neatness and organisedness helps.
>>
>> I had different prefixes used for the same class before. Many ElfData
>> functions started with "U" for some ancient reason. Like
>> USearchForward. Before USearchForward was the same as my
>> ElfData.Instr. That is hardly logical. Now USearchForward is
>> ElfData_InStr. I decided to replace ED_ED_ with just ElfData_,
>> because ED_ED_ looks silly. ED_ED_InStr would be more consistant, but
>> it's also confusing to a human and ElfData_InStr looks better. That's
>> the only inconsistancy left, now. A good one I think.
>>
>> In C++ you'll get the nice syntax benefit of not even needing to lock
>> and unlock stuff. You just set object references, and C++'s operator
>> overloading will take care of calling lock and unlock. So the RB code
>> will be very interchangable with C++!!! The same memory management
>> system, anyhow. The same class system, even. My ObjectPlatform even
>> has sublassing, constructors and destructors. And all of this in one
>> small .cpp file :)
>>
>> There are other additions to the ElfData plugin. Some very advanced
>> string processing functions far more sophisicated than anything
>> you've seen in the ElfData plugin, having DNA processing
>> applications.
>>
>> Other nice additions are the RingTree class I've made, which is a
>> very fast tree structure that has no cyclical reference problems like
>> a RingTree made in RB would do. It's very fast for inserts and
>> appends. And it's very flexible in moving RingTree nodes around and
>> about from place to place, but it doesn't allow impossible stuff like
>> making a parent a child of it's own child.
>>
>> Just like you can't do that in the Finder with folders...
>>
>> I've done the usual tightening up of stuff. The ElfData plugin should
>> be faster and use a little bit less RAM than before. I don't think it
>> can get any noticably faster now without me making bad code! I
>> managed the speed ups by simplifying and improving code. I don't want
>> to recode every function differently to gain < 1% of speed, (and
>> spend a year doing that) that is just silly. It's better to keep my
>> current high state of modularisation and code reuse.
>>
>> So basically my plugin is becoming more advanced (with respect to DNA
>> string processing), faster in general, more RAM efficient, a nice
>> RingTree class added, and being ported to C/C++. :)
>>
>> Given what I know about Java's JNI, I should be able to port the
>> ElfData plugin to Java also. But I won't do that unless someone pays
>> me, lol.
>>
>> --
>> http://elfdata.com/plugin/
>>
>> What does our work achieve, if it's not making the world a happier
>> place?
>> http://www.whatnextjournal.co.uk/Pages/Next/Happiness.html
>> When's the last time you thought deeply about how to improve our
>> lives?
>>
>>
>>
>>
>>
>>
>> Yahoo! Groups Links
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
> ------------------------ Yahoo! Groups Sponsor --------------------
> ~-->
> Get Bzzzy! (real tools to help you find a job). Welcome to the
> Sweet Life.
> http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/umvwlB/TM
> --------------------------------------------------------------------
> ~->
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>


--
http://elfdata.com/plugin/

What does our work achieve, if it's not making the world a happier
place?
http://www.whatnextjournal.co.uk/Pages/Next/Happiness.html
When's the last time you thought deeply about how to improve our lives?

Hi Theo,

Sounds exciting! Sounds like an awful lot of work too! Any idea when
it'll be ready?

Ronald Vogelaar
--
http://www.rovosoft.com

Theodore H. Smith wrote:

>
>I should probably make an update right about now.
>
>For the past few weeks I've been working on porting the ElfData
>plugin to C.
>
>It might sound like a strange thing to say "porting the ElfData
>plugin to C"... seeing as the ElfData plugin is *written* in C. But
>it still is work, a lot of work.
>
>C and C++ have no concept of objects (or refcounted objects for C++'s
>case). REALbasic does everything by refcounted objects. It's not so
>simple as just allocating structs with malloc and filling the data in
>them.
>
>How do you do REALUnlockObject upon an malloced void*??
>
>And what about nil object checking and type checking?
>
>What do do about all the functions that take and receive "string".
>You can't REALLockString upon a char* can you?
>
>There are huge architectural differences between REALbasic's
>environment and C.
>
>So what I've done is totally done away with REALbasic's plugin SDK.
>Instead I now am using my own "ObjectPlatform" as I've named it.
>ObjectPlatform is just a C/C++ API that lets you do proper object
>oriented stuff, using refcounted objects, type checking, nil object
>checking, in C.
>
>And it lets these objects you've created be accessable from C, or RB.
>The way I've made ObjectPlatform it should be possible to make the
>ElfData plugin work in Java also!
>
>However, most of the work I've had to do was to do with cleaning up
>my code and modernising it a little. So much work there. Mostly I was
>standardising my function names. Now I am using a convention I made
>up that goes like this. Domain_Class_Function. So for ElfData's MSR's
>Add function, you'd get ED_MSR_Add. This is because I hope my plugin
>to be used in many C/C++ projects, and it absolutely needs
>namespacing to keep it safe from name conflicts. ALso the
>standardising helps to make it easier on the eyes and easier to
>understand and remember.
>
>I've also had to spend great thought on scope. Some functions should
>just NOT be called by ElfData users, but only by internal classes.
>For this reason I've had to move a lot of function declarations from
>the .h files into the .cpp files, or even into private .h files which
>no ElfData user may include.
>
>In addition, I've made all the C functions have the same function
>name as the RB functions!
>
>Neatness and organisedness helps.
>
>I had different prefixes used for the same class before. Many ElfData
>functions started with "U" for some ancient reason. Like
>USearchForward. Before USearchForward was the same as my
>ElfData.Instr. That is hardly logical. Now USearchForward is
>ElfData_InStr. I decided to replace ED_ED_ with just ElfData_,
>because ED_ED_ looks silly. ED_ED_InStr would be more consistant, but
>it's also confusing to a human and ElfData_InStr looks better. That's
>the only inconsistancy left, now. A good one I think.
>
>In C++ you'll get the nice syntax benefit of not even needing to lock
>and unlock stuff. You just set object references, and C++'s operator
>overloading will take care of calling lock and unlock. So the RB code
>will be very interchangable with C++!!! The same memory management
>system, anyhow. The same class system, even. My ObjectPlatform even
>has sublassing, constructors and destructors. And all of this in one
>small .cpp file :)
>
>There are other additions to the ElfData plugin. Some very advanced
>string processing functions far more sophisicated than anything
>you've seen in the ElfData plugin, having DNA processing applications.
>
>Other nice additions are the RingTree class I've made, which is a
>very fast tree structure that has no cyclical reference problems like
>a RingTree made in RB would do. It's very fast for inserts and
>appends. And it's very flexible in moving RingTree nodes around and
>about from place to place, but it doesn't allow impossible stuff like
>making a parent a child of it's own child.
>
>Just like you can't do that in the Finder with folders...
>
>I've done the usual tightening up of stuff. The ElfData plugin should
>be faster and use a little bit less RAM than before. I don't think it
>can get any noticably faster now without me making bad code! I
>managed the speed ups by simplifying and improving code. I don't want
>to recode every function differently to gain < 1% of speed, (and
>spend a year doing that) that is just silly. It's better to keep my
>current high state of modularisation and code reuse.
>
>So basically my plugin is becoming more advanced (with respect to DNA
>string processing), faster in general, more RAM efficient, a nice
>RingTree class added, and being ported to C/C++. :)
>
>Given what I know about Java's JNI, I should be able to port the
>ElfData plugin to Java also. But I won't do that unless someone pays
>me, lol.
>
>--
>http://elfdata.com/plugin/
>
>What does our work achieve, if it's not making the world a happier
>place?
>http://www.whatnextjournal.co.uk/Pages/Next/Happiness.html
>When's the last time you thought deeply about how to improve our lives?
>
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>
>

I should probably make an update right about now.

For the past few weeks I've been working on porting the ElfData
plugin to C.

It might sound like a strange thing to say "porting the ElfData
plugin to C"... seeing as the ElfData plugin is *written* in C. But
it still is work, a lot of work.

C and C++ have no concept of objects (or refcounted objects for C++'s
case). REALbasic does everything by refcounted objects. It's not so
simple as just allocating structs with malloc and filling the data in
them.

How do you do REALUnlockObject upon an malloced void*??

And what about nil object checking and type checking?

What do do about all the functions that take and receive "string".
You can't REALLockString upon a char* can you?

There are huge architectural differences between REALbasic's
environment and C.

So what I've done is totally done away with REALbasic's plugin SDK.
Instead I now am using my own "ObjectPlatform" as I've named it.
ObjectPlatform is just a C/C++ API that lets you do proper object
oriented stuff, using refcounted objects, type checking, nil object
checking, in C.

And it lets these objects you've created be accessable from C, or RB.
The way I've made ObjectPlatform it should be possible to make the
ElfData plugin work in Java also!

However, most of the work I've had to do was to do with cleaning up
my code and modernising it a little. So much work there. Mostly I was
standardising my function names. Now I am using a convention I made
up that goes like this. Domain_Class_Function. So for ElfData's MSR's
Add function, you'd get ED_MSR_Add. This is because I hope my plugin
to be used in many C/C++ projects, and it absolutely needs
namespacing to keep it safe from name conflicts. ALso the
standardising helps to make it easier on the eyes and easier to
understand and remember.

I've also had to spend great thought on scope. Some functions should
just NOT be called by ElfData users, but only by internal classes.
For this reason I've had to move a lot of function declarations from
the .h files into the .cpp files, or even into private .h files which
no ElfData user may include.

In addition, I've made all the C functions have the same function
name as the RB functions!

Neatness and organisedness helps.

I had different prefixes used for the same class before. Many ElfData
functions started with "U" for some ancient reason. Like
USearchForward. Before USearchForward was the same as my
ElfData.Instr. That is hardly logical. Now USearchForward is
ElfData_InStr. I decided to replace ED_ED_ with just ElfData_,
because ED_ED_ looks silly. ED_ED_InStr would be more consistant, but
it's also confusing to a human and ElfData_InStr looks better. That's
the only inconsistancy left, now. A good one I think.

In C++ you'll get the nice syntax benefit of not even needing to lock
and unlock stuff. You just set object references, and C++'s operator
overloading will take care of calling lock and unlock. So the RB code
will be very interchangable with C++!!! The same memory management
system, anyhow. The same class system, even. My ObjectPlatform even
has sublassing, constructors and destructors. And all of this in one
small .cpp file :)

There are other additions to the ElfData plugin. Some very advanced
string processing functions far more sophisicated than anything
you've seen in the ElfData plugin, having DNA processing applications.

Other nice additions are the RingTree class I've made, which is a
very fast tree structure that has no cyclical reference problems like
a RingTree made in RB would do. It's very fast for inserts and
appends. And it's very flexible in moving RingTree nodes around and
about from place to place, but it doesn't allow impossible stuff like
making a parent a child of it's own child.

Just like you can't do that in the Finder with folders...

I've done the usual tightening up of stuff. The ElfData plugin should
be faster and use a little bit less RAM than before. I don't think it
can get any noticably faster now without me making bad code! I
managed the speed ups by simplifying and improving code. I don't want
to recode every function differently to gain < 1% of speed, (and
spend a year doing that) that is just silly. It's better to keep my
current high state of modularisation and code reuse.

So basically my plugin is becoming more advanced (with respect to DNA
string processing), faster in general, more RAM efficient, a nice
RingTree class added, and being ported to C/C++. :)

Given what I know about Java's JNI, I should be able to port the
ElfData plugin to Java also. But I won't do that unless someone pays
me, lol.

--
http://elfdata.com/plugin/

What does our work achieve, if it's not making the world a happier
place?
http://www.whatnextjournal.co.uk/Pages/Next/Happiness.html
When's the last time you thought deeply about how to improve our lives?

Hi Glazed,

It should work with RB 2005.

The only problem I'm aware of is with the memoryblock extension:
MemoryBlock.ElfData

This is fixed for the next release which I am working on right now.

Thanks for the feedback on my tips page! Let me know if you have
other questions.

I'm wondering if ElfData plugin v4.2 works with RB 2005. I've used
elfdata in the past with RB 4.x and loved it.

I'd like to update my old program that used elfdata.

I also love your Advanced Usage tips
http://www.elfdata.com/plugin/advancedusage.html. I'm new to RB (I've
had it for years but haven't used it enough to feel more than a
newbie). I refer to the tips every time I re-learn the basics.

glazed...

On 16 Mar 2005, at 14:06, Theodore H. Smith wrote:

>
> Just testing that this works!
>
Apparantly, it does!

Just testing that this works!

--
     www.elfdata.com/plugin/  -  groups.yahoo.com/group/elfdata
     ElfData: Industrial strength string processing, made easy.
"All things are logical. Putting free-will in the slot for premises in
a logical system, makes all of life both understandable, and free."