Bugs for Sorcery are reported here

[bugzilla-daemon AT bugs.sourcemage.org]

http://bugs.sourcemage.org/show_bug.cgi?id=6981


acedit AT armory.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|1.12.x                      |Untargetted future release




------- Additional Comments From acedit AT armory.com  2004-12-31 14:30 -------
(In reply to comment #9)
> (In reply to comment #7)
> > Magically makes me nervous because i dont want to have to learn how this 
> > all
> > magically works when it breaks :-/
> 
> it isn't really magic, its sufficient to read it bettet :)
You were the one who said it was magic, not me, so please dont contradict
yourself when im just responding to you:
"So all works magically :))"

For the record I did spend a significant amount of time reading the code and
giving you suggestions on how to fix problems I found, if you dont want to 
take
my suggestions into consideration then fine, I wont waste any more of my time
either.

> in any case, when (and if) it breaks I'll repair it 
Okay, cat ~/money > /dev/mouth. Repair the bugs I have found by inspection 
with
it :)

> 
> > 
> > What if the password ends in a / or some other field ends in a / theres 
> > still
> > too much fuzziness in this for me to be comfortable having to maintain it.
> 
> why should you maintain it... I'll maintain it if you don't understand it 
Well, in the real world its always good to have more than one person who can 
fix
problems with any piece of code, since obviously not everyone is going to be
around 100% of the time. Its also important for as many people as possible to 
be
able to read and understand as much of the code in sorcery as possible, just 
as
a general principle. Its already very complicated and tangled up (despite 
months
of detangling) so making things as simple as possible is always prefered, 
hence
my suggestions for a simpler uri format.

Perhaps what i should have said was just that it was too fuzzy, or shall I 
say,
ambiguous, for it to be considered robust. When I can come up with several 
ways
to confuse it off the top of my head, its not what i consider robust :)

> 
> > Perhaps using some other unique seperation character or making all the 
> > optional
> > fields manditory fields and instead saying that if they are empty, they 
> > dont
> exist?
> 
> unique separator should be compliant to standard uri description (like : or 
> /)
> and I use them. The others (not compliant to standard uri) cannot be or 
> sould
> not be used.
Sorcery doesnt specify that a uri has to conform to any specification, just 
that
there is a urltype:// at the front everything else if free form. Also, there
isnt a standard uri description for tla and if nothing else, the one you've 
made
up for tla is ambiguous. One way in which a language can be ambiguous is to 
have
a multiple parse trees for the same structure, i've pointed out to you ways 
that
can occur, especially since there are optional fields and characters that can
mean different things. One way it can be made un-ambiguous is to not overload
characters such that their meaning can be interprited in multiple ways. Ask a
linguist :)

I dont want to explain basic lexical, contextual and semantic analysis to you,
but realize the format you have choosen has multiple interpritations that can
only be differentiated on a semantic level, in other words you have to know 
the
meaning of the symbols and both interpritations to determine which one is
correct, when you have to do that, it is ambiguous. Computer languages are not
supposed to be ambiguous (IMO, but not larry walls'), especially not trivial 
uri
formats.

> 
> > 
> > I think it would be best to do away with the patch-level field 
> > althogether since
> > one could just as easily include it as part of the revision (and thats 
> > all the
> > code does with it anyway). Arch has to parse it anyway so why not let it 
> > do the
> > hard work rather than us having to do it also. Besides sorcery doesnt 
> > really
> > care what the patch level is.
> 
> not true... if is used to track spell version (have a look to emacs-planner 
> spell)

You missed the point, please re-read, and look at the relavent portions of 
code.
I didnt say that arch doesnt care about the version, I said sorcery doesnt 
care
about the patch level and therefore sorcery shouldnt have to parse it,
re-assemble it, and send it back to arch for it to re-parse when sorcery isnt
going to do anything with it in the first place (it doesnt). tla will accept a
category--branch--version field without a patch level just as easily as it 
will
one with a patch level (read about tla get), consequently the same regular
expression used to find that token will match either, thus the patch level 
field
is not needed, if the users wants to use a patch level they can, if they dont
its not used, and sorcery doesnt have to know either way. There is no need to
duplicate the logic in sorcery.

> 
> > 
> > There appears to be a bug as well: you dont handle the case of unpacking 
> > to a
> > pre-existing tarball without a patch level. If you remove the patch level
> > requirement and fold it into the revision then the problem goes away.
> 
> this is a 'filosofical' question... if a spell doens't request for a 
> specific
> patch level could mean which want the latest... so get it 
you dont understand the problem, this is a code related bug that upon trivial
code inspection i noticed. Obviously a greater amount of thought needs to go
into the various inputs that are allowed and the results that they would
produce. To reiterate, this is a bug. It is not a "philosophical" question, 
you
as the maintainer of the code need to address it...because if not, someone is
going to hit this problem while the code is live in the field and it will need
to be fixed.


> 
> > Re-assigning, please hand back to me when you're done.
> 
> here I'm... if you like url_tla as is (and I'll maintain it in future) ok...
> if not... make it better becouse as is I think it's ok
Well its not ok, and I told you why...and Ive been asking you to fix the
problems. You need to maintain it since thats what you're saying you'll do. I
could put the code in and then tell someone exactly how to break it, then have
them file a bug which you would have to fix (afterall, you're the maintainer).
Im just shortening the cycle. I gave you my advice on things i think are
incorrect and that sooner or later are going to be bugs that users of url_tla
will find and that you (as the maintainer) will need to fix, I'd rather fix 
them
now before other people hit them...

I also didnt have to spend time to give you suggestions on ways to fix these
problems, I could have sat on my soapbox about ambiguity, but instead i
suggested that several ways the ambiguity could be eliminated. If you dont 
want
to listen to my advice or suggestions then fine, but please dont ask me to fix
problems with code you are volunteering to maintain after I ask you to 
maintain
it :)

Since you're asking me to fix these bugs on your behalf then Im not going to 
be
able to work on this anytime in the near future, there are too many other 
higher
priority things that need to be fixed that have already been commited to the
1.12 schedule. This will just have to be postponed until you or someone else
wants to work on it. Sorry.

-- 
Configure bugmail: http://bugs.sourcemage.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.