cool , keep up the good work.

_________________
See my blog and collection website! . https://www.blog.amigaguru.com

Dude, sweet!

</wheresmycardude>

Great work!

Last edited by Chunder on 19-Jan-2006 at 09:04 AM.

_________________

keep at it!

_________________
Dark Lord Design Wicked Solutions For Damned Problems

Really a good idea !

Now here is another:
why stick to the way like C needs to do (Varargs) ?
why not create a more perlish way of passing arguments.
And here is how I would suggest to do it:


# Definition:
%args = ( "Tag" => Value, "Tag2" => Value2, ... );
# Alternative Definition:
$args { "Tag" } = Value;
$args { "Tag2"} = Value2;
$window_obj = WindowObject(%args);


or just:

$window_obj = WindowObject( "Tag" => Value, "Tag2" => Value2, ...);


Inside of WindowObject you can then cycle through this hash array with:


sub WindowObject {
my %taglist = ();
while( ($tag, $value) = each(%taglist)) {
print $tag." => ".$value."\n";
}
}


A problem might be the undefined way how a hash is stored in Perl and that the Taglist might get mixed while saving and reading it. You will have to try if it is possible to do it this way.

_________________

Quote:

Really a good idea !

Well, thanks!

Quote:

why stick to the way like C needs to do (Varargs) ? why not create a more perlish way of passing arguments. And here is how I would suggest to do it: # Definition: %args = ( "Tag" => Value, "Tag2" => Value2, ... ); # Alternative Definition: $args { "Tag" } = Value; $args { "Tag2"} = Value2; $window_obj = WindowObject(%args); or just: $window_obj = WindowObject( "Tag" => Value, "Tag2" => Value2, ...);

This looks nice but there are two fundamantal problems, with this approach.

1. Hashes are not ordered, and taglists must be. There is no way to ensure that you get your keys back in the order you put them in.
2. Taglists are lists of integers, which mean different things depending on the tag. Sometimes an string pointer sometimes literaly an integer. Perl variables on the other hand a totally untyped (in the C sense anyway).
My first attempt treated the list of perl values as a list of integers, but this had the side effect of converting the strings into their numeric value.

"12" would become 12
but
"twelve" would be come 0

My solution was to provide a third element to the tag array, tagtype. This allows perl to know what type to consider the value as when it it passed to the XS extension code.

The other way would be to "know" in adavance which tag was of which type, but this would require build large lookup tables, and make the XS code slow. Not to mention the increased oportunity for bugs.

Quote:

sub WindowObject { my %taglist = (); while( ($tag, $value) = each(%taglist)) { print $tag." => ".$value."\n"; } }

Ah, but WindowObject is not written in perl it's apiece of XS code ...

APTR
WindowObject(taglist, ...)
TagList * taglist
CODE:
RETVAL = IIntuition->NewObjectA(IWindow->WINDOW_GetClass(),NULL,(struct TagItem *)taglist);
OUTPUT:
RETVAL
CLEANUP:
Safefree(taglist);

where TagList has the typemap entry:

err well it's rather long so look in any of the typemap files in the archive.

One thing I haven't worked out is how to make al the xs files (one per module)
share the same typemap file. It's awfully tedious propagating changes other wise.

Thanks for the feedback. Bouncing Ideas of people always helps clarify the mind.

Last edited by broadblues on 19-Jan-2006 at 05:41 PM.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

the bomb!

now there is no excuse anymore for anybody to not start coding on the ami. perl is easy enough to pick up by anybody. programs can be small but powerful or large and complex and even more powerful.

excellent job!

Huh, if you want to do it perlish do:

my @tags = qw{MY_TAG, some_value, MY_NUMBER,0x12345, END_TAG};

foo(@tags);

sub foo {
$my_tag = shift;
$my_tag_value = shift;
# ... etc ...
}

_________________
Nicolas Mendoza

Still I don't see the neccessity to aktually *know* which type you are passing...
The Taglist will not be interpreted by your code but by the Reaction components.

Anyway this could be an alternative to hashes ?
http://pxpwdoc.pxperl.com/class_p_x_perl_wrap_1_1_c_perl_scalar.html
http://pxpwdoc.pxperl.com/class_p_x_perl_wrap_1_1_c_perl_array.html

Finally I would suggest a way of finding the types from a lookuptable, because I often use Reaction macros but without knowing the type. And a lookup in an array can't be so long compared to the time to create/change some value of a GUI element.
The argument that it's more work for you is true, but I guess it will implicate less bugs on the side of the user and much less work in creating a GUI for the users of this Perl-Reaction wrapper.

PS: I just want to share my opinion without any claim of being perfect or even well suited for your task

_________________

Quote:

Still I don't see the neccessity to aktually *know* which type you are passing... The Taglist will not be interpreted by your code but by the Reaction components.

The issue isn't on the perl side or the C side but in the transition between.

Perl is freely typed.
A perl function that is manipulating a taglist doesn't need to know the types of individual values (assming the perl programmer is competent enough not to add numbers to strings and expect them to stay strings, or concat string to number and expect them to stay numbers)

When you pass the tags from perl to the XS function though, a typemap is used to select which perl api function is used to interpret the value.

eg a string is converted with

char * string_value = (char *)SvPV_nolen(arg);

an int

int integer_value = (int)SvIV(arg);


But the ti_Data part of a tag item is always an integer.

if you use SvIV to convert it though the strings will get converted to their numeric equivalent, ie "12" will get interpret as the number 12, not as a pointer to the string "12" (cast to an integer) which is what C expects to see.

So you need a way of decided what type the value of any given tag value pair is in order to decide which conversion function to use.

You could use a look up tabe in the C code, but this would be exceptionally laborious to create, do you know haow many tags are defined for all the classes? A big number! There is no automatic way to to determine the type from the includes, as although the type is often mentioned it's in a comment which is not consistant.
It can be done but would take a long time, the other disdvantage is that every time new tags are added by class developers the extension would need updateing.

The other tecnique is to add an argument describing the type of the tag value, at the perl programming side.

@tags = (&TAG_NAME, &TT_TYPE, $value);

The range of types is fairly limted
TT_APTR for general pointers to gadgets and other data structres.
TT_STRPTR for pointers to strings
TT_ULONG, TT_LONG, TT_UWORD, TT_WORD, for numbers.

This is the approach I've taken.

Quote:

http://pxpwdoc.pxperl.com/class_p_x_perl_wrap_1_1_c_perl_scalar.html http://pxpwdoc.pxperl.com/class_p_x_perl_wrap_1_1_c_perl_array.html

These point to classes that give access to the function SvIV and the like that I described above, they could be used but it's alot more efficient to use XS functions on the XS (C code )side.

Quote:

because I often use Reaction macros but without knowing the type

I supect this is not really true. You will know if your passing a gadget, string, or number, the exact type is less important than the type of type. so to speak

What I can and probably will do in the long term is write proper blessed perl classes with accessor functions for the most common atributes, retaining the low levl access for compatabilty and for less common tags.

But this will be a way off yet. It's ages since I did any work on AWeb and really time I got back to it

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

Hi broadblues:
> It's ages since I did any work on AWeb and really time I got back to it

So don't give Perl_Reaction more priority than AWeb...
I think, if someone really needs to get a GUI for his Perl script, he can now do so.

_________________

Probably a stupid question, but........

How do I unarchive these on an A1.
I have tried the Bz2, and untarmeup from OS4Depot, but no joy.

Help please!!!

_________________
Peter Swallow.
A1XEG3-800 [IBM 750FX PowerPC], running OS4.1FE, using ac97 onboard sound.

"There are 10 types of people in the world: those who understand binary, and those who don't."

@Swoop

Just use UnArc, which is included with OS4.0 .

As the files are packed .tar files (bzip2 only works on single files IIRC) you will need to unpack twice but apart from that it works OK.

If I double click on the file "id3editor[1].tar.bz2", I get a multiview requester saying "unknown data type for id3editor[1].tar.bz2".

If I drag the file "id3editor[1].tar.bz2", onto the unarc icon on Amidock, I get a requester saying "error while unpacking "USBDISK:id3editor[1].tar.bz2 error reading input".

_________________
Peter Swallow.
A1XEG3-800 [IBM 750FX PowerPC], running OS4.1FE, using ac97 onboard sound.

"There are 10 types of people in the world: those who understand binary, and those who don't."

Quote:

If I double click on the file "id3editor[1].tar.bz2", I get a multiview requester saying "unknown data type for id3editor[1].tar.bz2".

Same here.

Quote:

If I drag the file "id3editor[1].tar.bz2", onto the unarc icon on Amidock, I get a requester saying "error while unpacking "USBDISK:id3editor[1].tar.bz2 error reading input".

That's weird, that doesn't happen to me. It works OK here. It just opens the usual unarc window, and I can select destination and then press the extract button, and it extracts to the .tar to the destination I selected, and then I open that in UnArc and do the same again. Maybe there's something wrong/different with the way you have UnArc set up in AmiDock?

Do you have start from Workbench or start from CLI on the UnArc icon? Try changing it to see if it helps...

Last edited by salass00 on 22-Jan-2006 at 04:18 PM.

The way I do this for tar.bz2 or .tar.gz files is to:

Open Unarc from it's icon in amidock.

Select the file and unarchive to ram:file.tar

reselect this one and unarc again.

If your feeling purist:...

do

cd ram:
bzip2 -d ram:id3editor.tar.bz2

followed by

tar -xf ram:ide3editor.tar

BTW you will need to get perl_Reaction.tar.bz2 before you could use id3editor.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad