Do other objects need to know the lock #, or just its state? Either way, couple simple methods take care of making that information available to other objects.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA
The system driver's methods can use the lock, but I don't think their clients need to know about it, unless you want a non-blocking method that can return "busy, try again later". But even then, it's not necessary for the calling object to know the lock number if the locking/unlocking is handled internally by the driver methods.
Its more about giving the user the ability to get the lock back. My "start" function returns the cog number. So, you could stop the cog later if you store than return value. But the lock value will be lost.
That's why I'm contemplating the idea of just using the lock number of whatever cog I got for the "start" function.
I'd rather not include a function just to tell you the lock number.
Kye said...
Its more about giving the user the ability to get the lock back. My "start" function returns the cog number. So, you could stop the cog later if you store than return value. But the lock value will be lost.
Ewwwww.. the user should not have to know the cog number. Encapsulate it in a stop() method. You can release the lock at the same time.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Kye said...
I just return the cog ID to be friendly.
How is it "friendly" to saddle the user with such details?!! Every object that starts another cog needs a stop method. One of the main advantages of using objects is encapsulation, wherein the user program is shielded from stuff it doesn't need to know about. In almost every case, the cog number and lock number are among those things that should remain hidden.
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 3/12/2010 5:12:13 AM GMT
Nonetheless, it needs to be included for those times that it does get used. Besides, most start methods begin with a call to stop, just to make sure it doesn't start redundant cogs. Moreover, how much room does a stop method require anyway? Not much. I'm afraid the benefits of encapsulation must always trump such a minuscule savings in code, Kye.
This is why we have compilers that leave out unused methods [noparse];)[/noparse] You need it, you can have it. You don't need it, it wastes no space [noparse]:)[/noparse]
Oh, @PhilPi.. stop methods ~ 2-4 longs is reasonable. 2/10ths of bugger all of nothing in the scheme of things.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Okay, I'll put in a stop method for the file system driver. I'm not making this standard on all my drivers however.
---
@Brad, Phil Pilgrim (PhiPi)·- Since I'm using the propeller tool, all unused functions are left in the code. The problem with saying that·two to four longs are okay to waste comes in when you are including about 16 or so drivers that follow this approach while keeping all safety features. This starts to eat into the very small heap·space and stack space available after writing the code. While·encapsulation is nice its also nicer to have left over data space.
... So here's a great example. Just taking everybodies advice today about making drivers more flexible·I managed to add a HEFTY extra 76 or so longs of spin code and other things across two drivers just to add support for dynamic pin setup. After doing this across my whole library I'll have added at least·500 or so extra longs to support "features" that aren't really needed -·all this stuff adds up.
One of my main goals with making my drivers has been to use "as little space as possible" without throwing out usefull run time features. So, by using constants in the code I save alot of space. I like having a larger heap and stack space.
It would be possible to use less space for dynamic pin setup, but then I would have to remove all the safety features that I always include in my code...
... Okay, its late, so I'll leave it right now with this. The stuff I have been asking about does not come from me being navie about encapsulation and flexibility, I'm just not interested in adding support for features that are marginal and can be moved to be in constants without severe affects.
In addition to the available compilers that can exclude unused code, as Brad mentioned, I've included my CLEAN program in the Propeller Backpack loader that's available here (zip). It can be used with any Propeller platform, though, in conjunction with the IDE. Just use the IDE to edit and save your code and the loader (with the "compress" option) to compile and upload it. That way any unused Spin methods will be removed.
Removing unused functions is only half of the truth. Making code flexible often also means to blow up the needed code. Let's have a look at FullDuplexSerial. You pass a lot of parameters to the start function which need stack space AND HUB RAM. Is it really needed? No, for a concrete project those parameters tend to be fixed!
So, I like Kye's point of view: make objects for the object exchange as tight as possible.
Imagine you have a complex project and the code does not fit because every driver used was just a little bit wasteful. If you have to squeeze out every single long out of all the drivers build by others you can loose any amount of time. You have to spot the points where you can improve the code, you have to retest, debug .....
Maybe we should start to have at least 2 SPIN files for the driver itself (plus the demo.spin), the hardcore driver-file plus a "newbie/comfort function-wrapper" SPIN.
This way we don't have the decision:
do we want to support professionals or do we want to support the beginners
And I'd prefere to have a constant section instead of oversized parameter lists for the start function. How hard can it be to teach the newbies read the comments and to check this section of constants??
Of course coding the newbie/comfort function-wrapper can be outsourced ;o)
As a person who deal with newbies (part-time programmers in the Halloween business) all the time I can tell you it can be very hard to get them to read comments.
As a professional, what I don't want to do is keep redundant copies of an object that have different pin definitions. At the moment I'm working on a project that uses two copies of FDS; using pin constants in this situation creates another redundancy problem.
So I will politely disagree: make objects that you keep to yourself as tight as possible, objects for public release should go the other direction and be as flexible as possible. Let the end user-tighten it up for a particular project should they desire.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA
That's exactly why I suggested to have a rating and why I suggested to have hardcore drivers and easy to use wrappers whereever possible. I think the object exchange should not address one kind of user or prefere one over the other. Kye and some others would like to use/add thight drivers without to much comfort and others simply need easy to understand objects.
Wasn't it you, Jon, who said it's good to have different objects doing the same thing ... why not have all in parallel, maybe grouped together, so you can easily find them and then you can select the one which has the right rating for you?
As we are a helpful bunch of propellerheads, there will soon be enough objects available having both, a runtime/size optimized and usability optimized version.
A publicly-posted object should not have to be twiddled and tweaked just to work on a particular platform. Call it success out of the box or instant gratification, whatever; it's an important property of any reusable code. Then, if an advanced user needs to massage it to make it smaller, he can. The rule is this: modify it to make it smaller; don't require modification just to make it work.
One of the great things about the Propeller (and Parallax) is that they're squarely aiming at the newbie / education market first, whilst encouraging the hardcore hobbyist / professional / commercial too. This openness and ease is what got me, and many others, into the Propeller in the first place.
True - it would be great if PropTool were to support multiple paths - or better still allow me to enter the path in the include statement PLEASE (or we could all use the excellent BST instead )
Bottom line: If anyone wants their objects to be used widely (al la FullDuplexSerial) thyewould be wise to make them easy to use - yes, even by the newbies. But I don't care if that means having the core object called from a "friendly" wrapper object
BTW: "If you don't have time to do it right, when will you find time to do it again?" - How true
Why souldn't someone who optimized a newbie-style driver in terms of code size/runtime or whatever not to be allowed to put the result back to the object exchange? Why does this kind of work has to be done again and again?
Why shouldn't people like kye and me, that like to do it another way, not be allowed to add possibly valuable drivers to the object exchange? If it's interesting for beginners but not easy enough, the community should be good enough to add wrappers or a modified version which is more beginner-friendly.
Give it a label and everybody knows what to expect.
Yes, parallax is successfull because they have a big newbie attraction, but only a few professionals that use the propeller for a project have the potential to increase the income more than a few more hobbyists. I bought 4 propellers within 1 year. If I keep using propellers hobby-style it won't be much more for the next year.
Don't missunderstand me ... I only want to say that the object exchange should give support for both, the beginners and the experienced users.
But if the rule is/stays: "modify it to make it smaller; don't require modification just to make it work" ... well ... I don't have to put my code into the object exchange.
Sorry Kye ... I think this thread somehow drifted away from the original subject ... I won't stress it any longer.
@JonnyMac & PhiPi: this time I am with MagIO2 (and Kye). Because of the prop big potential but small amount of memory it's good to have some code savings. Having pin assignments on constants leave them easy to change (saving precious space) and not necessarily increases object copies. OK, with PropToll this will make a lib folder impossible, but it’s due to the IDE limitations and not to the coding concept.
E.g.: Think of an object as an activex in the vb ide. There are properties like height, width that are used but not set through user code but still the ide remember them in the project’s main file (not in the ax). To speak propeller-ian what about a special con section that can be dynamically changed by the IDE and which values can be stored e.g. in a kind of old win INI file in the project folder (sounds like a nice job for BradC) where each object (instance) can have its own section with con values.
@Obex rating
In Italy we say that even the dog doesn’t wag the tail for nothing. Looking at the actual number of ratings I think that perhaps a mechanism that force them is necessary: download allowed only to registered users and after ten downloads you need to rate at least one of them to unlock a further one
Well, okay. If a person must insist on posting code that, say, assigns pins with constants, there's really no excuse not to furnish an alternative for those who want more flexibility:
{
[b]CON[/b] 'Uncomment this block for shorter code.
SDA_PIN = 23
SCK_PIN = 24
[b]PUB[/b] start
'...
}
'{ 'Uncomment this block for more flexible code.
[b]VAR[/b]
[b]byte[/b] SDA_PIN, SCK_PIN
[b]PUB[/b] start(sda, sck)
SDA_PIN = sda
SCK_PIN = sck
'}
Anything less is just plain laziness on the part of the programmer.
Granted, this would be easier with conditional compilation. But we don't have that in the Propeller Tool -- yet.
I'm going to update my objects to have support for variable pin assignments. After doing so I will have added alot of extra code to all of my objects.
But, at the same time I will also crush a small bug which I have noticed in pretty much all of my code and other pieces of OBEX code which is Lock Support. No one seems to include this... To have a truely capable objects I will need to include this type of support on my objects that have data structures in them like my serial driver.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA
-Phil
That's why I'm contemplating the idea of just using the lock number of whatever cog I got for the "start" function.
I'd rather not include a function just to tell you the lock number.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
-Phil
Ewwwww.. the user should not have to know the cog number. Encapsulate it in a stop() method. You can release the lock at the same time.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
-Phil
I just return the cog ID to be friendly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
Post Edited (Kye) : 3/12/2010 4:58:25 AM GMT
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 3/12/2010 5:12:13 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
-Phil
Oh, @PhilPi.. stop methods ~ 2-4 longs is reasonable. 2/10ths of bugger all of nothing in the scheme of things.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Okay, I'll put in a stop method for the file system driver. I'm not making this standard on all my drivers however.
---
@Brad, Phil Pilgrim (PhiPi)·- Since I'm using the propeller tool, all unused functions are left in the code. The problem with saying that·two to four longs are okay to waste comes in when you are including about 16 or so drivers that follow this approach while keeping all safety features. This starts to eat into the very small heap·space and stack space available after writing the code. While·encapsulation is nice its also nicer to have left over data space.
... So here's a great example. Just taking everybodies advice today about making drivers more flexible·I managed to add a HEFTY extra 76 or so longs of spin code and other things across two drivers just to add support for dynamic pin setup. After doing this across my whole library I'll have added at least·500 or so extra longs to support "features" that aren't really needed -·all this stuff adds up.
One of my main goals with making my drivers has been to use "as little space as possible" without throwing out usefull run time features. So, by using constants in the code I save alot of space. I like having a larger heap and stack space.
It would be possible to use less space for dynamic pin setup, but then I would have to remove all the safety features that I always include in my code...
... Okay, its late, so I'll leave it right now with this. The stuff I have been asking about does not come from me being navie about encapsulation and flexibility, I'm just not interested in adding support for features that are marginal and can be moved to be in constants without severe affects.
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
Post Edited (Kye) : 3/12/2010 8:00:32 AM GMT
In addition to the available compilers that can exclude unused code, as Brad mentioned, I've included my CLEAN program in the Propeller Backpack loader that's available here (zip). It can be used with any Propeller platform, though, in conjunction with the IDE. Just use the IDE to edit and save your code and the loader (with the "compress" option) to compile and upload it. That way any unused Spin methods will be removed.
-Phil
So, I like Kye's point of view: make objects for the object exchange as tight as possible.
Imagine you have a complex project and the code does not fit because every driver used was just a little bit wasteful. If you have to squeeze out every single long out of all the drivers build by others you can loose any amount of time. You have to spot the points where you can improve the code, you have to retest, debug .....
Maybe we should start to have at least 2 SPIN files for the driver itself (plus the demo.spin), the hardcore driver-file plus a "newbie/comfort function-wrapper" SPIN.
This way we don't have the decision:
do we want to support professionals or do we want to support the beginners
And I'd prefere to have a constant section instead of oversized parameter lists for the start function. How hard can it be to teach the newbies read the comments and to check this section of constants??
Of course coding the newbie/comfort function-wrapper can be outsourced ;o)
As a professional, what I don't want to do is keep redundant copies of an object that have different pin definitions. At the moment I'm working on a project that uses two copies of FDS; using pin constants in this situation creates another redundancy problem.
So I will politely disagree: make objects that you keep to yourself as tight as possible, objects for public release should go the other direction and be as flexible as possible. Let the end user-tighten it up for a particular project should they desire.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA
Wasn't it you, Jon, who said it's good to have different objects doing the same thing ... why not have all in parallel, maybe grouped together, so you can easily find them and then you can select the one which has the right rating for you?
As we are a helpful bunch of propellerheads, there will soon be enough objects available having both, a runtime/size optimized and usability optimized version.
-Phil
Till then, my approach is somewhat better because your going to need to copy all the drivers anyway to different folders for each project.
Why not then change the pins for those copies? Unless you keep everything in one giant folder... ugh...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
One of the great things about the Propeller (and Parallax) is that they're squarely aiming at the newbie / education market first, whilst encouraging the hardcore hobbyist / professional / commercial too. This openness and ease is what got me, and many others, into the Propeller in the first place.
True - it would be great if PropTool were to support multiple paths - or better still allow me to enter the path in the include statement PLEASE (or we could all use the excellent BST instead
Bottom line: If anyone wants their objects to be used widely (al la FullDuplexSerial) thyewould be wise to make them easy to use - yes, even by the newbies. But I don't care if that means having the core object called from a "friendly" wrapper object
BTW: "If you don't have time to do it right, when will you find time to do it again?" - How true
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.com
Announcement: To cut costs in the current economic climate, we have switched-off the light at the end of the tunnel.
Why shouldn't people like kye and me, that like to do it another way, not be allowed to add possibly valuable drivers to the object exchange? If it's interesting for beginners but not easy enough, the community should be good enough to add wrappers or a modified version which is more beginner-friendly.
Give it a label and everybody knows what to expect.
Yes, parallax is successfull because they have a big newbie attraction, but only a few professionals that use the propeller for a project have the potential to increase the income more than a few more hobbyists. I bought 4 propellers within 1 year. If I keep using propellers hobby-style it won't be much more for the next year.
Don't missunderstand me ... I only want to say that the object exchange should give support for both, the beginners and the experienced users.
But if the rule is/stays: "modify it to make it smaller; don't require modification just to make it work" ... well ... I don't have to put my code into the object exchange.
Sorry Kye ... I think this thread somehow drifted away from the original subject ... I won't stress it any longer.
E.g.: Think of an object as an activex in the vb ide. There are properties like height, width that are used but not set through user code but still the ide remember them in the project’s main file (not in the ax). To speak propeller-ian what about a special con section that can be dynamically changed by the IDE and which values can be stored e.g. in a kind of old win INI file in the project folder (sounds like a nice job for BradC) where each object (instance) can have its own section with con values.
@Obex rating
In Italy we say that even the dog doesn’t wag the tail for nothing. Looking at the actual number of ratings I think that perhaps a mechanism that force them is necessary: download allowed only to registered users and after ten downloads you need to rate at least one of them to unlock a further one
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· Propeller Object Exchange (last Publications / Updates);·· Vaati's custom search
{ [b]CON[/b] 'Uncomment this block for shorter code. SDA_PIN = 23 SCK_PIN = 24 [b]PUB[/b] start '... } '{ 'Uncomment this block for more flexible code. [b]VAR[/b] [b]byte[/b] SDA_PIN, SCK_PIN [b]PUB[/b] start(sda, sck) SDA_PIN = sda SCK_PIN = sck '}Anything less is just plain laziness on the part of the programmer.
Granted, this would be easier with conditional compilation. But we don't have that in the Propeller Tool -- yet.
-Phil
I'm going to update my objects to have support for variable pin assignments. After doing so I will have added alot of extra code to all of my objects.
But, at the same time I will also crush a small bug which I have noticed in pretty much all of my code and other pieces of OBEX code which is Lock Support. No one seems to include this... To have a truely capable objects I will need to include this type of support on my objects that have data structures in them like my serial driver.
Anyway,
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,