1. Improvement that Everybody Will Agree With: Versioning

I'd like to have a built-in procedure to track version numbers. It would work
like this:

In your program or library, you would put this line:

-- I track my versions by date, release, and patch
-- It's probably overkill, but I like it and it's very easy to use.
-- for example, 2007.01.12-1.0
addVersionData( "myLib.e", 2007, 1, 12, 1, 0 )
-- addVersionData( filename, year, month, day, release, patch )

This just adds to a global list managed by the interpreter. Then, you can
do something like this:

r = {2007,1,12,2,1}
v = getVersionData( "myLib.e" )
if versionSerial(v) >= versionSerial(r) then -- or some similar functionality
   -- good to go
else
   -- warn
end if

Also need

v = getVersionData( "" ) -- returns version data for all current items

so I can loop through them if necessary.

No, I could not do this myself, so I'll contribute to a monetary fund for
developers to do...

Hey, that's another good idea! Let's start a fund and assign bounties to
items that have gotten the green light for implementation. I've seen the
idea of bounties somewhere else... sounds good for getting things done.

-=ck
"Programming in a state of Euphoria."
http://www.cklester.com/euphoria/

new topic     » topic index » view message » categorize

2. Re: Improvement that Everybody Will Agree With: Versioning

Great idea IMHO.
Currently I put in comments with that same info right next to the
include statement.. old school, but works for me. Eg
include win32lib.ew  -- v0.57.9 24th June 2002

Another improvement: add a CRC/checksum value to the stored identification data.
That way the included file could be tested to ensure its the correct version.
Maybe dust off Rob's statement count checker of earlier Eu versions? 

BTW, is there any way / function that will tell us the path of where
the include actually came from, from withing Eu code? (Not looking at debug
trace or cross reference output)

Regards
Alan

new topic     » goto parent     » topic index » view message » categorize

3. Re: Improvement that Everybody Will Agree With: Versioning

Ok, let me get the bounty idea rolling.
I'll send $50 via paypal to whoever creates a nice function for confirming
includes via CRC. It needs to be a built in function, platform independant.

-- instead of
include get.e
include /home/alano/euphoria/includes/get.e
include "c:\\dir withspace\\myincludes\\get.e"
-- you could have
chk_include("get.e",12345678) 
chk_include("/home/alano/euphoria/includes/get.e",12345678)
chk_include("c:\\dir withspace\\myincludes\\get.e",12345678)
-- and the interpreter will halt with a trappable error message
-- if the 12345678 checksum is incorrect.


IMHO, exactly where a included file came from is important mostly because
you want you have the expected include only. The other reason is to include
the correct libraries when packaging your app. The version, date, author
etc of the included file is a nice to have (IMHO) because thats just there
 mostly to know which file you have included - now covered by the check.

Anybody interested in the admittedly paltry $50 can contact me at 
alan dot oxley at alindigo dot com.
Any senior/knowledgeable list member wanna be the judge?

Regards
Alan

new topic     » goto parent     » topic index » view message » categorize

4. Re: Improvement that Everybody Will Agree With: Versioning

Alan Oxley wrote:
> 
> Ok, let me get the bounty idea rolling.
> I'll send $50 via paypal to whoever creates a nice function for confirming
> includes via CRC. It needs to be a built in function, platform independant.
> 
> }}}
<eucode>
> -- instead of
> include get.e
> include /home/alano/euphoria/includes/get.e
> include "c:\\dir withspace\\myincludes\\get.e"
> -- you could have
> chk_include("get.e",12345678) 
> chk_include("/home/alano/euphoria/includes/get.e",12345678)
> chk_include("c:\\dir withspace\\myincludes\\get.e",12345678)
> -- and the interpreter will halt with a trappable error message
> -- if the 12345678 checksum is incorrect.
> </eucode>
{{{

> 
> IMHO, exactly where a included file came from is important mostly because
> you want you have the expected include only. The other reason is to include
> the correct libraries when packaging your app. The version, date, author
> etc of the included file is a nice to have (IMHO) because thats just there
>  mostly to know which file you have included - now covered by the check.
> 
> Anybody interested in the admittedly paltry $50 can contact me at 
> alan dot oxley at alindigo dot com.
> Any senior/knowledgeable list member wanna be the judge?
> 
> Regards
> Alan


Hi

smile

A can of worms if ever there was one!

Chris

new topic     » goto parent     » topic index » view message » categorize

5. Re: Improvement that Everybody Will Agree With: Versioning

Alan Oxley wrote:
> 
> Ok, let me get the bounty idea rolling.
> I'll send $50 via paypal to whoever creates a nice function for confirming
> includes via CRC. It needs to be a built in function, platform independant.
> 
> }}}
<eucode>
> -- instead of
> include get.e
> include /home/alano/euphoria/includes/get.e
> include "c:\\dir withspace\\myincludes\\get.e"
> -- you could have
> chk_include("get.e",12345678) 
> chk_include("/home/alano/euphoria/includes/get.e",12345678)
> chk_include("c:\\dir withspace\\myincludes\\get.e",12345678)
> -- and the interpreter will halt with a trappable error message
> -- if the 12345678 checksum is incorrect.
> </eucode>
{{{

> 
> IMHO, exactly where a included file came from is important mostly because
> you want you have the expected include only. The other reason is to include
> the correct libraries when packaging your app. The version, date, author
> etc of the included file is a nice to have (IMHO) because thats just there
>  mostly to know which file you have included - now covered by the check.
> 
> Anybody interested in the admittedly paltry $50 can contact me at 
> alan dot oxley at alindigo dot com.
> Any senior/knowledgeable list member wanna be the judge?
> 
> Regards
> Alan

Why does it need to be builtin?

Chris Bensler
~ The difference between ordinary and extraordinary is that little extra ~
http://empire.iwireweb.com - Empire for Euphoria

new topic     » goto parent     » topic index » view message » categorize

6. Re: Improvement that Everybody Will Agree With: Versioning

Alan Oxley wrote:
> 
> Another improvement: add a CRC/checksum value
I would certainly not use any (open source) software that stopped working the
moment I edited/fixed a bug in it!

> BTW, is there any way / function that will tell us the path of where
> the include actually came from, from withing Eu code? (Not looking at debug
> trace or cross reference output)
Neither do I want software that dies unless get.e is in C:\euphoria\include.
I could easily provide a development utility that lists the exact includes,
along with "version" info.

Regards,
Pete

new topic     » goto parent     » topic index » view message » categorize

7. Re: Improvement that Everybody Will Agree With: Versioning

Pete Lomax wrote:
> 
> Alan Oxley wrote:
> > 
> > Another improvement: add a CRC/checksum value
> I would certainly not use any (open source) software that stopped working the
> moment I edited/fixed a bug in it!
> 
> > BTW, is there any way / function that will tell us the path of where
> > the include actually came from, from withing Eu code? (Not looking at debug
> > trace or cross reference output)
> Neither do I want software that dies unless get.e is in C:\euphoria\include.
> I could easily provide a development utility that lists the exact includes,
> along with "version" info.
> 
> Regards,
> Pete

Pete, you can always generate a new checksum if the included file changes.
That would be another function of course, with the "chk_include".
In fact having to do this can be seen as an advantage, you can't miss
the fact that the included file contents has changed. 
Possibly it would be easier to use standard includes while developing, and
the chk_include replacment when bundling / distributing an app.

I'm not proposing a complete replacement of the standard include at all.
Use the chk_include or don't - its up to you.

My reason for wanting the chk_include as a builtin was so that you didn't
need an include to have chk_include availible. But if most people believe
it will be unused bloat added to the Euphoria code, then having
the functionality in a library will be fine.

Chris, why would this be a can of worms? Reply privately if you want.

Do we have anyone in favour of the chk_include then ?

Regards
Alan

new topic     » goto parent     » topic index » view message » categorize

8. Re: Improvement that Everybody Will Agree With: Versioning

Alan Oxley wrote:
> Do we have anyone in favour of the chk_include then ?

Not me, really.

But I would like to have a version() function for the interpreter so a program
(or include file) can query the version of the interpreter. Obviously programs
using it would not be backwards compatible.

--
"Any programming problem can be solved by adding a level of indirection."
--anonymous
"Any performance problem can be solved by removing a level of indirection."
--M. Haertel
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.

new topic     » goto parent     » topic index » view message » categorize

9. Re: Improvement that Everybody Will Agree With: Versioning

Pete Lomax wrote:

> Neither do I want software that dies unless get.e is in C:\euphoria\include.

Well, I do. IMHO the inconvenience of that outweighs the frustration
and debugging time of including wrong code. An analogy for me is 
uninitialised variables. I think we all agree that assign before use is
a good thing.
Again, the old include will always be availible if you want to use it.
 
> I could easily provide a development utility that lists the exact includes,
> along with "version" info.

Sounds good. I'll use it! I'd still like the chk_include though as I want
an error if the included file is no the one I expect. 

Regards
Alan

new topic     » goto parent     » topic index » view message » categorize

10. Re: Improvement that Everybody Will Agree With: Versioning

Alan Oxley wrote:
> 
> Pete Lomax wrote:
> > 
> > Alan Oxley wrote:
> > > 
> > > Another improvement: add a CRC/checksum value
> > I would certainly not use any (open source) software that stopped working
> > the
> > moment I edited/fixed a bug in it!
> > 
> > > BTW, is there any way / function that will tell us the path of where
> > > the include actually came from, from withing Eu code? (Not looking at
> > > debug
> > > trace or cross reference output)
> > Neither do I want software that dies unless get.e is in C:\euphoria\include.
> > I could easily provide a development utility that lists the exact includes,
> > along with "version" info.
> > 
> > Regards,
> > Pete
> 
> Pete, you can always generate a new checksum if the included file changes.
> That would be another function of course, with the "chk_include".
> In fact having to do this can be seen as an advantage, you can't miss
> the fact that the included file contents has changed. 
> Possibly it would be easier to use standard includes while developing, and
> the chk_include replacment when bundling / distributing an app.
> 
> I'm not proposing a complete replacement of the standard include at all.
> Use the chk_include or don't - its up to you.
> 
> My reason for wanting the chk_include as a builtin was so that you didn't
> need an include to have chk_include availible. But if most people believe
> it will be unused bloat added to the Euphoria code, then having
> the functionality in a library will be fine.
> 
> Chris, why would this be a can of worms? Reply privately if you want.
> 
> Do we have anyone in favour of the chk_include then ?

I never said it would be a can of worms. (I assume you were addressing me?)
Although I have considered the issue of versioning libraries quite extensively
before for AHEAD and it is rather problematic.

I don't see a problem with using checksums.
I agree that if a file has been edited, then it is no longer the same version,
even if that change was just to update the copyright header. So having a new
checksum makes sense. I can see it being a PITA though, and many ppl would likely
just avoid using it.

A stable, distributed library should never be modified without properly
reversioning it.

RDS stamped files are checksummed BTW, ppl don't have a problem to use those.
Maybe we could utilize that somehow to provide a level of authenticity to
various files.

I would recommend a version library over a builtin though, if at all possible.

I agree with Pete that I would not want to have to hardcode paths.
./ and EUINC/ are just as valid as EUDIR/include/ plus you will be gritting your
teeth everytime you want to use a file made for one persons environment on
another. (I use F:\Empire\ as my installation folder for example)

Why not just include version info in the file name?

include win32lib-v0.5.97.ew

is just as validating as

include win32lib.ew
chk_include("win32lib.ew",{0,5,97})

Perhaps what is needed though is a way to query the interpretter for the full
path of the current file. This way, the library authors could put checksums in
their libs which could be verified automatically by using the fullpath to do the
checksum test on the file.

Something like
version_checksum(1234567890)

Then the end programmer can call a function such as
validate_checksums()

or

if checksum_failed() then...

Another feature that could be handy is to determine if an application is being
run as interpretted, or bound, or translated to C.

I think maybe this is all just overkill however.
Filenames that reflect the version are a much better solution in my opinion.

I agree with Jason in providing a builtin version() function though, to
determine the version of the interpetter.

Chris Bensler
~ The difference between ordinary and extraordinary is that little extra ~
http://empire.iwireweb.com - Empire for Euphoria

new topic     » goto parent     » topic index » view message » categorize

11. Re: Improvement that Everybody Will Agree With: Versioning

Chris Bensler wrote:
> I never said it would be a can of worms. (I assume you were addressing me?)
> Although I have considered the issue of versioning libraries quite extensively
> before for AHEAD and it is rather problematic.
Just to clarify, ChrisBurch2 said it...

http://www.listfilter.com/EUforum/m11987.html

--
"Any programming problem can be solved by adding a level of indirection."
--anonymous
"Any performance problem can be solved by removing a level of indirection."
--M. Haertel
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.

new topic     » goto parent     » topic index » view message » categorize

12. Re: Improvement that Everybody Will Agree With: Versioning

Chris Bensler wrote:
> 
> I never said it would be a can of worms. (I assume you were addressing me?)

I missed Chris Burch's post, despite looking twice! :/


Chris Bensler
~ The difference between ordinary and extraordinary is that little extra ~
http://empire.iwireweb.com - Empire for Euphoria

new topic     » goto parent     » topic index » view message » categorize

13. Re: Improvement that Everybody Will Agree With: Versioning

Chris Bensler wrote:
> 
> I would recommend a version library over a builtin though, if at all possible.

It has to be built-in because some people will use it and some won't.
If I am not using the versioning library and I include a library that calls

   addVersionData( "mylib.e", 2007, 1, 12, 1, 3 )

then it will crash with a procedure-not-found error. If it's built-in, that
concern goes bye-bye. Use it or don't, the interpreter will always understand.

> Why not just include version info in the file name?
> include win32lib-v0.5.97.ew
> is just as validating as
> include win32lib.ew
> chk_include("win32lib.ew",{0,5,97})

Potentially hundreds of programs will have to be modified because of the
change in FILENAME. That isn't right.

It's much better to change the versioning internally and never have to
change "include win32lib.ew." Updated libraries should be pluggable in
my opinion. That is, I can swap out one version of the library with
another and not have to change any of the code in my program.

I suggested this because I have a content management framework I've
developed and it has lots of modules (includes). I use the CMF on multiple
websites. At times, I'll make a change to one of the include files that I
need to copy to the other sites. I just want to make sure every installation
of the CMF is up-to-date. This is made easier with my versioning library,
but I'd like to have versioning built-in in case I want to use some of these
components in other projects. When I'm using other people's libraries- such
as Tommy Carlier's Kanarie- it doesn't have versioning info in it, but I
put it in there manually because I need to track that.

I guess it's easy enough to just type "include versions.e" at the top of
the main program file when something crashes due to procedure-not-found
errors... :)

<a href="http://cklester.com/?page=main&content=viewarticle&id=26">Building
Blocks Content Management Framework</a>

new topic     » goto parent     » topic index » view message » categorize

14. Re: Improvement that Everybody Will Agree With: Versioning

Alan Oxley wrote:
> 
> Pete Lomax wrote:
> > 
> > Alan Oxley wrote:
> > > 
> > > Another improvement: add a CRC/checksum value
> > I would certainly not use any (open source) software that stopped working
> > the
> > moment I edited/fixed a bug in it!
> > 
> > > BTW, is there any way / function that will tell us the path of where
> > > the include actually came from, from withing Eu code? (Not looking at
> > > debug
> > > trace or cross reference output)
> > Neither do I want software that dies unless get.e is in C:\euphoria\include.
> > I could easily provide a development utility that lists the exact includes,
> > along with "version" info.
> > 
> > Regards,
> > Pete
> 
> Pete, you can always generate a new checksum if the included file changes.
> That would be another function of course, with the "chk_include".
> In fact having to do this can be seen as an advantage, you can't miss
> the fact that the included file contents has changed. 
> Possibly it would be easier to use standard includes while developing, and
> the chk_include replacment when bundling / distributing an app.
> 
> I'm not proposing a complete replacement of the standard include at all.
> Use the chk_include or don't - its up to you.
> 
> My reason for wanting the chk_include as a builtin was so that you didn't
> need an include to have chk_include availible. But if most people believe
> it will be unused bloat added to the Euphoria code, then having
> the functionality in a library will be fine.
> 
> Chris, why would this be a can of worms? Reply privately if you want.

No need, I don't mind. Have you seen the discussion these sort of ideas generate
between Chris Bensler (not me, same initials though), Pete lomax, Jason Gade,
Matt Lewis, etc. 

Its fantastic.

Discussions can rage for days about whether something should be a pointer,
referenced by another pointer, passed back and forth. Sometimes they even
think they're insulting each other. Marvellous!

There may be no gentle way to put this, without someone feeling insulted, in
some
way or other, but this list has two levels - the high brow, and those that
want to use Euphoria, because it gets the job done in a simple simple way.

This is yet another argument for the forum style (bangs head on nearest
brick wall). WHO USES OFF LINE READING ANYMORE? Who needs the digest mailed
to them? How many other languages use the list form, rather than the forum
form. (I think Chris Bensler has missed a couple of posts because of Topica lag)

I have the utmost faith that this will never happen. Euphoria could create
a forum to rival XMB et al, but all previous attempts to branch to forums
have fallen by the wayside

Oh well, soap box rant over. I have the utmost respect for the above mentioned
developers. But sometimes you're just so ...... pedantic!

> 
> Do we have anyone in favour of the chk_include then ?

No, but I would be in favour of an internal version()

Chris Burch

ps - does this mean I have to rename some of my own CB_?????() functions?


> 
> Regards
> Alan

new topic     » goto parent     » topic index » view message » categorize

15. Re: Improvement that Everybody Will Agree With: Versioning

c.k.lester wrote:
> It has to be built-in because some people will use it and some won't.
     ^^^
> If I am not using the versioning library and I include a library that calls
> 
>    addVersionData( "mylib.e", 2007, 1, 12, 1, 3 )
> 
> then it will crash with a procedure-not-found error. If it's built-in, that
> concern goes bye-bye.
<snip>
> I guess it's easy enough to just type "include versions.e" at the top of
> the main program file when something crashes due to procedure-not-found
> errors... :)

You obviously know roughly what I am about to say.


I cannot believe you just said that.


I thought you had more sense.


Hang your head in shame.


. 
. 
. 

. 
. 
. 

OK, I jest blink
Pete

new topic     » goto parent     » topic index » view message » categorize

16. Re: Improvement that Everybody Will Agree With: Versioning

ChrisBurch2 wrote:
> Have you seen the discussion these sort of ideas generate
> between Chris Bensler (not me, same initials though), Pete lomax, Jason 
> Gade, Matt Lewis, etc. 
> 
> Its fantastic.
Glad to see we are amusing someone blink)
> 
> Discussions can rage for days about whether something should be a pointer,
> referenced by another pointer, passed back and forth. Sometimes they even
> think they're insulting each other. Marvellous!
> 
> There may be no gentle way to put this, without someone feeling insulted, 
> in some way or other, but this list has two levels - the high brow, and 
> those that want to use Euphoria, because it gets the job done in a simple 
> simple way.
By "high brow" I assume you mean tech-heads talking b*ll***s.
Trust me, I'd rather be one of those rare really clever people that actually get
paid for using it ;-((

> But sometimes you're just so ...... pedantic!
You should never use more than three dots in an ellipsis.

Regards,
Pete

new topic     » goto parent     » topic index » view message » categorize

17. Re: Improvement that Everybody Will Agree With: Versioning

Pete Lomax wrote:

>> But sometimes you're just so ...... pedantic!

> You should never use more than three dots in an ellipsis.

<PEDANTRY>

He didn't.

</PEDANTRY>

-- 
Craig

new topic     » goto parent     » topic index » view message » categorize

18. Re: Improvement that Everybody Will Agree With: Versioning

Pete Lomax wrote:
> 
> ChrisBurch2 wrote:
> > Have you seen the discussion these sort of ideas generate
[SNIP]
> > But sometimes you're just so ...... pedantic!
> You should never use more than three dots in an ellipsis.
> 
> Regards,
> Pete

Pete, it's 3 dots for an ellipsis, unless it's at the end of a sentence, then
four....

--
jon

p.s. fascinating exchanges, guys, from the #1 lurker. Euphoria is going
somewhere, no doubt.

new topic     » goto parent     » topic index » view message » categorize

19. Re: Improvement that Everybody Will Agree With: Versioning

Pete Lomax wrote:
> 
> ChrisBurch2 wrote:
> > Have you seen the discussion these sort of ideas generate
> > between Chris Bensler (not me, same initials though), Pete lomax, Jason 
> > Gade, Matt Lewis, etc. 
> > 
> > Its fantastic.
> Glad to see we are amusing someone blink)
> > 
> > Discussions can rage for days about whether something should be a pointer,
> > referenced by another pointer, passed back and forth. Sometimes they even
> > think they're insulting each other. Marvellous!
> > 
> > There may be no gentle way to put this, without someone feeling insulted, 
> > in some way or other, but this list has two levels - the high brow, and 
> > those that want to use Euphoria, because it gets the job done in a simple 
> > simple way.
> By "high brow" I assume you mean tech-heads talking b*ll***s.
> Trust me, I'd rather be one of those rare really clever people that actually
> get paid for using it ;-((
> 
> > But sometimes you're just so ...... pedantic!
> You should never use more than three dots in an ellipsis.

LOL .... cheers Pete!

> 
> Regards,
> Pete


http://euallegro.wikispaces.com
http://members.aol.com/chriscrylex/euphoria.htm
http://uboard.proboards32.com/
http://members.aol.com/chriscrylex/EUSQLite/eusql.html

new topic     » goto parent     » topic index » view message » categorize

20. Re: Improvement that Everybody Will Agree With: Versioning

ChrisBurch2 wrote:
> 
> > Chris, why would this be a can of worms? Reply privately if you want.
> 
> No need, I don't mind. Have you seen the discussion these sort of ideas
> generate
> between Chris Bensler (not me, same initials though), Pete lomax, Jason Gade,
> Matt Lewis, etc. 
> 
> Its fantastic.
> 
> Discussions can rage for days about whether something should be a pointer,
> referenced by another pointer, passed back and forth. Sometimes they even
> think they're insulting each other. Marvellous!
> 
> There may be no gentle way to put this, without someone feeling insulted, in
> some
> way or other, but this list has two levels - the high brow, and those that
> want to use Euphoria, because it gets the job done in a simple simple way.

There are those wo like Eu for what it is. And there are those who like Euphoria
for what it could be. I'm one of the latter.

I used to like it for what it is, but then I outgrew it. Now it's still a rose,
but I keep pricking myself on the thorns.

> This is yet another argument for the forum style (bangs head on nearest
> brick wall). WHO USES OFF LINE READING ANYMORE? Who needs the digest mailed
> to them? How many other languages use the list form, rather than the forum
> form. (I think Chris Bensler has missed a couple of posts because of Topica
> lag)
> 
> I have the utmost faith that this will never happen. Euphoria could create
> a forum to rival XMB et al, but all previous attempts to branch to forums
> have fallen by the wayside

The only way that we could make a forum work is if it's officially supported.

We went through the same thing for the chat channel. Ppl tried for years.
Finally I made a page for Rob to stick on the RDS site and the channel has
lasted for several years now. Still slow in there, but a success none the less in
regards to providing the service.

I could revamp the Empire site to be more 'euphoric'. IMO invision power board
is the best forum software going right now. Unfortunately, IPB no longer offers
an unpaid version. It may be worth buying into though anyways.
They do a very good job with security, and ppl can subscribe to categories,
forums or threads to receive in email if they prefer that way.
Worth looking into at least. Afaik, PHPBB doesn't do subscriptions, which would
be the next choice.


> Oh well, soap box rant over. I have the utmost respect for the above mentioned
> developers. But sometimes you're just so ...... pedantic!

Ever watched the senate in action? :)


> > Do we have anyone in favour of the chk_include then ?
> 
> No, but I would be in favour of an internal version()
> 
> Chris Burch
> 
> ps - does this mean I have to rename some of my own CB_?????() functions?

Only time I ever use my initials for code is to disambiguate a version number
when I've forked it for prototype modifications. I'll try to remember to use CBB
from now on though ;)
(Don't tell me that's your middle initial too! :P)

Chris Bensler
~ The difference between ordinary and extraordinary is that little extra ~
http://empire.iwireweb.com - Empire for Euphoria

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu