Gossamer Forum: Products: Gossamer Links: Development, Plugins and Globals: bug in dir Converter: Page 2

Mar 13, 2003, 5:15 AM

Paul

Veteran (19537 posts)

Mar 13, 2003, 5:15 AM

Post #26 of 46

Shortcut

Re: [webmaster33] bug in dir Converter In reply to

Quote:

It is needed in my development process. Otherwise when checking for syntax with -c option I will get error.

It is not needed, you should use something like the following:

perl -c -I/path/to/admin/directory

Quote:

Data::Dumper is used for debugging in development phase. I don't care about GT::Dumper (which module is not standard in Perl, but Data::Dumpler is).

You are missing the point. GT::Dumper isn't a standard perl module, but it will be installed on EVERY copy of Links SQL using your plugin and it is specific to Links SQL making it a more suitable choice.

Quote:

You are right, that they could be declared in one step.
But usage of 13 "my" declarations does simply not matter in fact of the speed.

Yes it does.

Quote:

The optimization you suggest is unnecessary, since in the full execution time these 13 "my"-s are executed in less than 1%. Optimization is unnecessary for such small speed gain.

Not only should speed optimizations be used when necessary (and where you even admit you could improve it) but also aesthetically and syntactically it would lead to an improvement.

Quote:

This does not mean any problems...
It's my programming style, and I like using not instead of ! for easier readibility.

There is a difference in precedence between "not" and "!" - it's not a question of programmingstyle. I suggest you read the perldocs.

Quote:

Not incorrect. Both gives the same result, when comparing 2 integers

Again read the perldocs. It is incorrect usage, any perl programmer will confirm that.

Quote:

Same as above, with the addition, that there are NO number comparisions using 'eq'!!!
You meant this code part?: $IN->param("step1") eq "1" .... also in html sourse: <INPUT TYPE="CHECKBOX" NAME="step1" VALUE="1">
All input parameters you get from the form are strings, so you statement is simply not true.
So it causes NO problems.

See my answer above.

Quote:

Paul, Yogi: you should try out this small example

You example doesn't prove anything as you aren't even using any blocks Sly

Quote:

So your comment was NOT valid in CGI mode. Unfortunately under mod_perl the my() declaration usage on file level will not work if it's used under mod_perl. The mod_perl is the only reason to correct it, and avoid usage of my() declarations on file level.

Sorry, I'm afraid you are incorrect again. It has nothing to do with mod_perl.

Quote:

Go ahead Paul, do hundreds of tests on my plugin, discover all the possible problems it has, and tell me all the problems!

I didn't have to do hundreds of test...a quick scan through the code was enough to spot several potential problems.

If you choose not to correct them then only yourself and the people using your plugins will lose out in the end...I am just trying to assist you :)

I do think though you need to view the perldocs, especially regarding the use of my(0 and globals and also eq/ne/!=/==

Last edited by:

Paul: Mar 13, 2003, 5:17 AM

Mar 13, 2003, 5:31 AM

Paul

Veteran (19537 posts)

Mar 13, 2003, 5:31 AM

Post #27 of 46

Shortcut

Re: [webmaster33] bug in dir Converter In reply to

Here's a good tutorial you may want to look at...

http://www.perldoc.com/...perators-(Rightward)

Mar 13, 2003, 7:02 AM

webmaster33

Veteran (2312 posts)

Mar 13, 2003, 7:02 AM

Post #28 of 46

Shortcut

Re: [Paul] bug in dir Converter In reply to

Hehe, that proves my right Smile

Quote:

Logical Not
Unary "not" returns the logical negation of the expression to its right. It's the equivalent of "!" except for the very low precedence.

Best regards,
Webmaster33

Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...

Mar 13, 2003, 7:07 AM

webmaster33

Veteran (2312 posts)

Mar 13, 2003, 7:07 AM

Post #29 of 46

Shortcut

Re: [Paul] bug in dir Converter In reply to

Paul,
Thanks again for your advices. But I reasoned well my answers in my last post.
As well as these:

Quote:

It is not needed, you should use something like the following:
perl -c -I/path/to/admin/directory

Yes, theoritically that may be possible, but note that I don't use perl command line for my developments.
I use a UltraEdit programming editor, which helps me a lot in my development. It has a Tool which makes possible to run compilers, interpreters, and can also include the file Path, but only with backslashes. No path with forward slashes available.
So currently the perl -I option is not usable for me.

Quote:

GT::Dumper

We already discussed that, no reason to dispute again about it.

Quote:

>>You are right, that they could be declared in one step.
>But usage of 13 "my" declarations does simply not matter in fact of the speed.
>Yes it does.

Paul, please do the profiling of my plugin, ok?
Then, when you have some proofs, come back and tell me the exact results, and prove your right!
(Note! I said Profiling, not Benchmarking!)
Until that time don't talk into the air...

Ask any professional programmer about optimizations.
Syntactical & aesthethic optimizations are mostly just waste of the time.
The reason for a working code change:
1) add new feature
2) correct bug
3) add comments to make it self descriptive or make it clear to understand for later developments
4) code optimizations, usually for speed (after profiling!!!)

Quote:

There is a difference in precedence between "not" and "!" - it's not a question of programmingstyle.

I explained that, and you can try safely.
Try this code:

Code:
my @foo = ('a','b','c'); 
my @bar = ('a','b','c'); 
print "Content-Type: text/plain\n\n"; 
(scalar @foo eq scalar @bar) ? (print 'equal') : (print 'NOT equal');

The example will display you 'equal'.
As I wrote, in case we use 'eq' or 'ne', the numbers are converted to strings, then compared.
The example above shows I'm right.
I don't say 'eq' or 'ne' is correct to use for numbers, but works well without problem.
Also BTW read perdoc perldata:

Quote:

Scalars aren't necessarily one thing or another. There's no place to declare a scalar variable to be of type ``string'', type ``number'', type ``reference'', or anything else. Because of the automatic conversion of scalars, operations that return scalars don't need to care (and in fact, cannot care) whether their caller is looking for a string, a number, or a reference. Perl is a contextually polymorphic language whose scalars can be strings, numbers, or references (which includes object

Quote:

Paul, if once you write bullshit, at least don't repeat it :)
I would use $IN->param("step1") eq "step1", then your comment would not have any base at all.
But even if I pass value "1", is valid to use 'eq', since 1 is understood my interpreter as string, when compared with 'eq'...

Quote:

You example doesn't prove anything as you aren't even using any blocks

Uh, you should not stick to your wrong knowledge. You should read the perldoc first.
In the code I listed, not the block environment matters (since we assume it is in module file), but the fact that the plugin is a module (file).

Quote:

Check my comments above about file level my() usage.
Therefore is very likely that mod_perl is affected by file level my() usage. That's why I move them to function level.

Quote:

I didn't have to do hundreds of test...a quick scan through the code was enough to spot several potential problems.

Again. There were only 1 potential problems in your list with 10 items, the mod_perl compatibility.
Also there was the 1 bug, what Yogi discovered: usage of 'category' instead 'Category'.

Quote:

If you choose not to correct them then only yourself and the people using your plugins will lose out in the end...

Nobody will lose anything! Please don't mislead the users!
As above I described, there was 1 bug, and 1 potential problem!
Both will be solved in the v1.0.5 bugfix version!
Will be released, when was tested to work.

Quote:

I am just trying to assist you :)

You are always welcome to assist my developments. Wink

Quote:

I do think though you need to view the perldocs

I did read the docs. The one who need the docs is you. Wink

Best regards,
Webmaster33

Mar 13, 2003, 7:07 AM

Paul

Veteran (19537 posts)

Mar 13, 2003, 7:07 AM

Post #30 of 46

Shortcut

Re: [webmaster33] bug in dir Converter In reply to

I didn't say you were wrong using "not" - I said "!" would be more appropriate. I just wanted to point out that there is a difference and you should be aware of it.

There are also differences with:

and => &&
or => ||

..and so on.

The faq I linked to explains most of them.

Mar 13, 2003, 7:14 AM

Paul

Veteran (19537 posts)

Mar 13, 2003, 7:14 AM

Post #31 of 46

Shortcut

Re: [webmaster33] bug in dir Converter In reply to

Quote:

Syntactical & aesthethic optimizations are mostly just waste of the time.

Yikes, you are telling me syntax doesn't matter?....eek, let's hope the clients that pay for your plugins feel the same Crazy

I've provided a list of possible bugs so it's up to you whether you implement any of the changes mentioned or not. You may find implementing at least a few of the changes will save you headaches in the long run.

Anyhow, I've said what I wanted to say so I'm done :)

I guess you have a lot to learn :)

Edit:

One last thing, I'd prefer you didn't tell me what I am telling you is bullshit - that is a little ignorant.

Last edited by:

Paul: Mar 13, 2003, 7:16 AM

Mar 13, 2003, 8:13 AM

webmaster33

Veteran (2312 posts)

Mar 13, 2003, 8:13 AM

Post #32 of 46

Shortcut

Re: [Paul] bug in dir Converter In reply to

Quote:

Syntactical & aesthethic optimizations are mostly just waste of the time.

Yikes, you are telling me syntax doesn't matter?....eek, let's hope the clients that pay for your plugins feel the same

1) Please don't try to manipulate my clients!
2) You missed the point!
I said, syntactical & aesthethic optimizations, which is NOT same as syntax error, or a bug where you get different result because you used BAD syntax!
BAD syntax is NOT the same as syntactical optimizations!

Quote:

I've provided a list of possible bugs

Again. NONE of them was bug in CGI mode!
In viewpoint of mod_perl, the last one was bug.

Quote:

I guess you have a lot to learn :)

There are a lot things I did not use in Perl, for example sockets and a lot other things.
You should know, that when you think you know enough, you will find out that you still did not learnt enough. All professionals knows that.
And yes, I still have a lot things to learn.

However, in this thread, YOU made some big mistakes, so I suppose you should learn some Perl & SQL... Wink

How can you tell that MySQL table names are all upper case??? Sigh!
Yogi, likely mistyped it, and you copied his words... I read docs, when I'm not sure in something, unlike you. You should read some Perl & MySQL docs...
You also had earlier a big mistake in HTML, when you sticked to your wrong opinion that target="new" is the good attrib to always open new window... Laugh

I said target="_blank" is the correct solution.
So don't tell me, what I should learn! I know my knowledge limits!

Quote:

I'd prefer you didn't tell me what I am telling you is bullshit when it appears you don't actually understand what you are talking about.

Well, once you say such things, that
instead of

Code:
'$IN->param("step1") eq "1"'

you say I should use

Code:
'$IN->param("step1") == "1"'

then yes, I will say you don't know, what you are talking about!
Sorry for the thing, that I used bullshit as expression, but that does not change the fact,
that you was not right.

Best regards,
Webmaster33

Mar 13, 2003, 8:40 AM

klauslovgreen

Enthusiast (671 posts)

Mar 13, 2003, 8:40 AM

Post #33 of 46

Shortcut

Re: [webmaster33] bug in dir Converter In reply to

guys....

http://www.ameinfo.com

Mar 13, 2003, 9:03 AM

Paul

Veteran (19537 posts)

Mar 13, 2003, 9:03 AM

Post #34 of 46

Shortcut

Re: [webmaster33] bug in dir Converter In reply to

Like I said above, I've already finished the dicsussion :)

I have several plugins to make for a client so that's certianly more important and rewarding.

Luckily I can laugh off your post above. Feel free to tell me I need to read the docs and learn perl, blah blah. Fortunately I have confidence in my own ability, and experience to match so that's really all that matters.

As they say, the proof is in the pudding and my plugins rock Tongue

Mar 13, 2003, 9:29 AM

webmaster33

Veteran (2312 posts)

Mar 13, 2003, 9:29 AM

Post #35 of 46

Shortcut

Re: [Paul] bug in dir Converter In reply to

Paul,
You have confidence about your knowledge. Why you feel forced to state that your plugins rocks? Tongue

Your clients and my clients will decide, which work they like better. Period.

P.S.: We are fighting like 2 cocks. Isn't that funny? Smile

I also have a lot work to do, so leaving now.

Bye,
W33

Mar 13, 2003, 9:32 AM

Paul

Veteran (19537 posts)

Mar 13, 2003, 9:32 AM

Post #36 of 46

Shortcut

Re: [webmaster33] bug in dir Converter In reply to

Quote:

You have confidence about your knowledge. Why you feel forced to state that your plugins rocks?

Because that is the reflection of my confidence Smile

Quote:

P.S.: We are fighting like 2 cocks. Isn't that funny?

I hope you mean the animal and not the one legged trouser snake :)

Shall we call a truce?

Mar 29, 2003, 10:00 AM

webmaster33

Veteran (2312 posts)

Mar 29, 2003, 10:00 AM

Post #37 of 46

Shortcut

Re: [ridesworld] bug in dir Converter In reply to

The bug in DirName converter plugin was corrected, and the v1.0.5 version is available for download in the Download area of admin interface.
Changes are listed in the history.txt file in the plugin archive file.

Best regards,
Webmaster33

Mar 29, 2003, 10:07 AM

cwi

User (56 posts)

Mar 29, 2003, 10:07 AM

Post #38 of 46

Shortcut

Re: [webmaster33] bug in dir Converter In reply to

Found this line at the top of the main .pm file:

use lib 'z:/WORK/WWW.INDYGO.HU/CGI-BIN/lsql/admin';

Mar 29, 2003, 10:15 AM

webmaster33

Veteran (2312 posts)

Mar 29, 2003, 10:15 AM

Post #39 of 46

Shortcut

Re: [cwi] bug in dir Converter In reply to

It should not affect the plugin usage.
Comment it out if disturbs you.

EDIT: In case if this disturbs anybody, I commented out the mentioned line, and updated the plugin in Download area.

Best regards,
Webmaster33

Last edited by:

webmaster33: Mar 29, 2003, 10:27 AM

Mar 29, 2003, 11:20 AM

Paul

Veteran (19537 posts)

Mar 29, 2003, 11:20 AM

Post #40 of 46

Shortcut

Re: [webmaster33] bug in dir Converter In reply to

Do you know what stuff like this is doing:

Code:
my $count3 = $dirname =~ s/($cfg_chars_invalid_replace)($cfg_chars_invalid_replace)+/$cfg_chars_invalid_replace/g if $cfg_merge_mode;

(I'm referring to the assignment of $count3).

I just want to check it's doing what you think it's doing.

Mar 29, 2003, 12:13 PM

webmaster33

Veteran (2312 posts)

Mar 29, 2003, 12:13 PM

Post #41 of 46

Shortcut

Re: [Paul] bug in dir Converter In reply to

$count3 will have the number of replacements the s///g; was done.

Do you want to test my knowledge? Cool

Best regards,
Webmaster33

Mar 29, 2003, 12:37 PM

Paul

Veteran (19537 posts)

Mar 29, 2003, 12:37 PM

Post #42 of 46

Shortcut

Re: [webmaster33] bug in dir Converter In reply to

Aha it's a good job I asked, it doesn't do that =)

It will either return nothing or 1 depending on whether the regex matched or not.

Last edited by:

Paul: Mar 29, 2003, 1:17 PM

Mar 29, 2003, 1:09 PM

webmaster33

Veteran (2312 posts)

Mar 29, 2003, 1:09 PM

Post #43 of 46

Shortcut

Re: [Paul] bug in dir Converter In reply to

Paul, you feel glad now, yeah? Cool

You think you found another bug in my plugin, yeah? No, you didn't. Cool

You try to find bugs in my job, yeah?
No problem, until you do that for the purpose to help. However I feel again (as already happened several times), that you are doing that just to prove that my Perl knowledge is bad, and you are the great Perl programmer. Mad

BTW: there is no perfect people, so even you may have bugs in your plugin. But in this case, what you wrote, there is NO bug in my plugin. Works exactly as it should work!
The difference between us is, that I don't dig in your plugins to find bugs in them...

And again: Please Paul, stay away from the threads I started, ok? I will not miss you. I hate your childish habit, that you always feel you need to prove that you are right and you are better than others... Uh, brrrr.

And now about the sillyness you wrote: you should read perldoc perlop before you post such things...
But to save you time I paste here what the doc says:

Quote:

s/PATTERN/REPLACEMENT/egimosx
Searches a string for a pattern, and if found, replaces that pattern with the replacement text and returns the number of substitutions made. Otherwise it returns false (specifically, the empty string).

Paul, so you are wrong again! Cool

Best regards,
Webmaster33