1. RE: NO!!!!

> From: sephiroth _ [mailto:euman2376 at yahoo.com]

Since you aren't addressing anyone in particular here, as a current
developer of win32lib, I'll see if I can make some sense of all this...

> What have you DONE to Win32lib?!?!?! Look at that code! It looks like
> someone shrouded...no, scrambled the code and tried to put it back
> together! 

Are you looking at the shortened version (not intended for debugging--see
the docs) or the full version?

> In my entire life, I have not SEEN such bad style! Have you
> considered how this will affect debugging? Maybe you don't want us
> debugging YOUR messed up code!

Most of the restructuring has been Derek's work, but I haven't had any
problems debugging (and I've been doing a lot of that lately).  In fact, I
think it's easier to debug now.  Like anything, it takes a little effort to
figure out something that you didn't code, but since it's still very similar
to the previous stuff (and fairly well commented), it's not too tough.

Can you give some more specifics?  What stylistic problems?  What bugs?

> This library is incompatible with earlier versions.

Yes.  So what?  That's what happens to new software.  Especially when it's
less than version 1.0.  I think the changes have really improved the library
with minimal compatibility issues.

> You've already gone too far.

Huh?

> Now others are using
> this ABOMINATION of David Cuny's original! How COULD you???

You mean aside from David hinting for some time that he'd like for someone
to take over the project so he could get on with his life? :)  Seems to me
that the demand for the lib contradicts your feelings on it.

Now I have some questions for you:

Have you been using win32lib for long?  
When did you first notice that the lib was changing?
Where have you been--I mean, who the hell are you to be calling things
abominations?  (I don't recognize this email address as having been
around--unless just as a lurker--for very long)
Why do you think that it's an abomination?
What would you like to see put in/taken out of win32lib?

Matt Lewis

PS For Ferninand:  Your message made less sense than Sephiroth_'s did.

new topic     » topic index » view message » categorize

2. RE: NO!!!!

sorry...i really went overboard there. i guess i was using the shortened 
version? where do i get the full version? i think there must be a 
problem where it handles the drag & drop stuff.

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

3. RE: NO!!!!

Before you panic, I hope you realize that Win32Lib includes two 
different versions:

Win32Lib.ew has been stripped of comments and unneeded white space to 
reduce file size (for when you want to distibute source code for your 
program).

Win32Lib_full.ew is what you would use if you are trying to debug 
Win32Lib.  It has all of the formatting and comments in tact.

I believe the program 'conv055.exw' does the comment/whitespace 
stripping...

-- Brian

sephiroth _ wrote:
> What have you DONE to Win32lib?!?!?! Look at that code! It looks like
> someone shrouded...no, scrambled the code and tried to put it back
> together! In my entire life, I have not SEEN such bad style! Have you
> considered how this will affect debugging? Maybe you don't want us
> debugging YOUR messed up code! This library is incompatible with
> earlier versions. You've already gone too far. Now others are using
> this ABOMINATION of David Cuny's original! How COULD you???

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

4. RE: NO!!!!

> From: sephiroth _ [mailto:euman2376 at yahoo.com]

> sorry...i really went overboard there. i guess i was using 
> the shortened 
> version? where do i get the full version? i think there must be a 
> problem where it handles the drag & drop stuff.

Check out 

Matt Lewis

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

5. RE: NO!!!!

>>  This library is incompatible with earlier versions.  

>So? No one promised compatibility, in fact, until v1.0 we are >warning 
>people
>that there are going to be minimal attempts to be backward >compatibile. 
>We
>won't try to be incompatible, but if a better way is discovered to do
>something, then it might be put in even if it will "break" existing 
>>code.

Of course the simple solution would be to provide past versions
for download as well as the current version.
This means NO code really gets broken.
For example:
  winlibV001.ew comes out and someone writes program01.exw
then later:
  winlibV002.ew comes out, someone downloads program01.exw and
  downloads winlibV002 and program01.exw no longer runs without
  crashing.
If there was a note in program01.exw declaring the winlib version
it was written for, and that same version was still available on
the web, program01.exw would always be able to run because they
could download the version it required.

Granted it takes a little more web space, but thats life.
Zipped text files are often much smaller anyway.
If patch program updates are used, they may not be as reliable
unless they can somehow be tested really good, but that may
introduce another bug testing phase into the works also.

Note that in several open source projects this is
exactly the way it is handled.  Its also known that some programmers
have a preference for older library versions also, while they wait
for bugs in new versions to be fixed or whatever, or they simply
'like' using the older version that they had built several
routines for and dont want to wade through thousands of lines of code
in order to update their (previously working) program to the new
standard.
In the meantime, i strongly recommend anyone building a program
or library around winlib to include the winlib version they used
in the zip along with their program in order to assure the user
gets the correct version.

This should help some...

Good luck with it.
--Al

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

6. RE: NO!!!!

Al Getz writes:
>Of course the simple solution would be to provide past versions
>for download as well as the current version.

Thanks Al, this is a good point.

I started doing this back n November of last year. The site
http://users.bigpond.net.au/homepage/euphoria/euphoria.htm has v0.54 and its
patches plus 0.55 and its patches. I'll see if I can find earlier versions
on put them in the site too.

-----
cheers,
Derek Parnell

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

7. RE: NO!!!!

How about seperating it into seperate libs? To keep the libs specific to 
Win32Lb.. give them the extension *.w32
Just symantics, but well worth the trouble if you are able to reduce the 
size of the main lib..
Who says I WANT to use listboxes, edit controls.. groups, or even 
buttons for that matter..
Take windows for example..
There is the imminent KERNEL.DLL, then there are the extras.. CTRL.DLL, 
CTRL3D.DLL, etc.. etc..

I think the size of the main lib can be diminished to a tenth of it's 
current size if you are able to restructure it. maybe use OOP
The kernel should include the main event handlers.. and OOP processor, 
if you choose to develop your own..
It shouldn't include any classes.. They should be seperate libs.. Just 
like WINDOWS..
I hate to say they did something right, but they didn't make billions 
for nothing..

Keep in mind, this is just my thoughts, I'm definitely no expert, and I 
DO see that it would be VERY difficult.. but in the long run, it would 
be easier, as well as more convenient for everyone, if you could do it 
that way..
For win32lib coders as well as users..
The library would be much easier to expand, and probably we would see a 
lot more user contributed additions, if this were possible..
Instead of fumbling through.. what is it now 285?.. of code in one 
module.. break it up!! (and that's the compacted version!!)

If I could simply write the class module with the events, properties, 
and handlers that I would need for my class alone, I would at least try 
to do so..
As it is now.. it's certainly not possible for me to even attempt to 
change anything.. I have tried, and gave up after having to work my way 
through the maze of code that is there..
Users should never have to look at the kernel..
Just the individual class libs.. From these they could see what things 
they are able to do ,and what they aren't..

To accomplish this, win32lib would definitely need a lot of 
restructuring.. possibly even re-writing the whole thing.. but to me 
this should be priority #1..
Do you wish to continue to implement everything that people see as a 
neccessity, or to tell them that they can't have it? Would be much 
easier to tell them to code it themselves..

I wish I could help, but I'm far from proficient in Win coding, not to 
mention even very familiar with win32lib coding, let alone win32lib 
SOURCE coding..


Chris

Derek Parnell wrote:
> Hi Everyone,
> 
> I'd be more than happy to take ideas and submissions for Euphoria Coding
> Standards. I'm trying to put one together right now for use with 
> Win32lib
> but the ESL could use it too.
> 
> ----- Original Message -----
> From: "sephiroth _" <euman2376 at yahoo.com>
> 
> > What have you DONE to Win32lib?!?!?! Look at that code! It looks like
> > someone shrouded...no, scrambled the code and tried to put it back
> > together!
> 
> Thank you - I tried very hard to make it obscure.
> 
> Not really. I wrote a utility (eucompress.exw) that takes any euphoria 
> file
> and tries to reduce its size by stripping comments and unrequired
> whitespace. If I can be bothered, I'll go the next step and remove
> unrequired linefeeds too. I was going to rename identifiers to smaller 
> ones
> but debugging would then be just too hard.
> 
> The real code is in win32lib_full.ew. This contains better whitespace 
> usage
> and comments and the library documentation.
> 
> > In my entire life, I have not SEEN such bad style!
> 
> Still new to programming then are you? blink
> 
> > This library is incompatible with earlier versions.
> 
> So? No one promised compatibility, in fact, until v1.0 we are warning 
> people
> that there are going to be minimal attempts to be backward compatibile. 
> We
> won't try to be incompatible, but if a better way is discovered to do
> something, then it might be put in even if it will "break" existing 
> code.
> 
> -----
> cheers,
> Derek Parnell
>

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

Search



Quick Links

User menu

Not signed in.

Misc Menu