|
kalos
|
 |
« on: May 30, 2012, 04:37:21 PM » |
|
Hello!
which programming/scripting language has the largest number of immediately available functions?
either built-in or in repositories
Thanks!
|
|
|
|
|
Logged
|
|
|
|
|
Renegade
|
|
« Reply #1 on: May 30, 2012, 07:27:58 PM » |
|
That's a bit of the wrong question to ask. It all depends on what you want to do.
Perl has a massive amount of software available for it. Similar with PHP. There are tons of libraries in JavaScript as well. Then again, C/C++ has a huge number of tools written for it.
And all of those languages serve different purposes that none of the others are really suitable for.
It makes more sense to ask, "I want to do X. What languages are suitable for that and what are the advantages of each?" One of the advantages for a language is having a large amount of ready-to-use code for it, like PHP or C, etc., in the form of either code or libraries.
Does that help to kind of answer what you were wondering?
|
|
|
|
|
Logged
|
|
|
|
|
kalos
|
|
« Reply #2 on: May 31, 2012, 03:36:19 AM » |
|
okay, I want to do all the basic stuff, like text manipulation, calculations between numbers, dates, file operations, etc with as many functions as possible prebuilt, so I wont have to built my own
also, I want to interact with other GUIs (manipulate and automate them), do data binding easily, and ability to organize files
also, I want to easily create GUI
last, I want to save standalone exes and store files in them, able to take relatively big amount of data (some 10s of MB)
|
|
|
|
|
Logged
|
|
|
|
|
|
4wd
|
|
« Reply #3 on: May 31, 2012, 04:06:47 AM » |
|
AutoIt or AutoHotkeylast, I want to save standalone exes and store files in them, able to take relatively big amount of data (some 10s of MB) Do you mean you want the resultant executable to contain data as a resource within the executable? ie. The data is extracted out of the executable at runtime. And if so, static (the data will not be changed after compilation) or variable (self-modifying executable)?
|
|
|
|
|
Logged
|
Four wheel drive: Helping you get stuck faster, harder, further from help...........and it's no different on this forum  |
|
|
|
kalos
|
|
« Reply #4 on: May 31, 2012, 07:43:02 AM » |
|
- Do you mean you want the resultant executable to contain data as a resource within the executable?
yes
- static (the data will not be changed after compilation) or variable (self-modifying executable)?
variable
|
|
|
|
|
Logged
|
|
|
|
|
4wd
|
|
« Reply #5 on: May 31, 2012, 09:09:03 AM » |
|
- Do you mean you want the resultant executable to contain data as a resource within the executable?
yes
This you can do with AutoIt, (I've done it), although I don't know exactly how big a resource you can embed. - static (the data will not be changed after compilation) or variable (self-modifying executable)?
variable
This will be very hard to do using AutoIt - I don't think anyone over on the forums has done it. The only way I can think of without recompiling each time is to directly write the changed data into a copy of the original executable but that means you'll be stuck with a fixed data size, (and who knows what else needs to be taken care of - beyond my knowledge). The only other way of doing it that I can think of is a self-modifying, self-extracting archive which should be possible using 7zip, WinRAR, WinZIP, etc. Is there a specific reason why the data has to be embedded within the executable? |
|
|
|
|
Logged
|
Four wheel drive: Helping you get stuck faster, harder, further from help...........and it's no different on this forum |
|
|
|
kalos
|
|
« Reply #6 on: May 31, 2012, 02:50:52 PM » |
|
Is there a specific reason why the data has to be embedded within the executable?
for archiving, portability, flexibility, availability, etc purposes the documents (files) should always accompany the executable and should be immediately available |
|
|
|
|
Logged
|
|
|
|
|
4wd
|
|
« Reply #7 on: May 31, 2012, 09:16:59 PM » |
|
the documents (files) should always accompany the executable and should be immediately available I think your best choices are either a self-repacking archive or just having the files in the same directory. For the archive you make it self-extracting with a batch file that runs following extraction that will run your program, wait until it closes, then repack the archive with changed data. That's the easiest way I can see of doing it but someone else probably has a better idea. |
|
|
|
|
Logged
|
Four wheel drive: Helping you get stuck faster, harder, further from help...........and it's no different on this forum |
|
|
|
Stoic Joker
|
|
« Reply #8 on: June 01, 2012, 09:09:51 AM » |
|
the documents (files) should always accompany the executable and should be immediately available I think your best choice s are either a self-repacking archive or just having the files in the same directory. +1 - f0dder did a great job with the self editing password storage utility fskrit, but... It requires some rather tricky shenanigans with the temp folder to pull off. I really don't think that it would be safe - which he also expressed - for a complex data storage application. The OTF unpack/repack sounds good, but it also mandates a pristine exit to avoid data loss (eek!). Same directory storage would also allow for much more flexible development options as you wouldn't be tied to something that offered low level system code access. |
|
|
|
|
Logged
|
|
|
|
|
4wd
|
|
« Reply #9 on: June 01, 2012, 09:01:29 PM » |
|
The OTF unpack/repack sounds good, but it also mandates a pristine exit to avoid data loss (eek!). I wasn't going to mention that aspect because there's absolutely no way to guard against it - it's just part and parcel with the whole 'self-contained' thing. You could bundle up the executable and it's dependant files using something like Cameyo but having your data separate in the same directory is a much better option than bundling it. |
|
|
|
|
Logged
|
Four wheel drive: Helping you get stuck faster, harder, further from help...........and it's no different on this forum |
|
|
|
Shades
|
|
« Reply #10 on: June 03, 2012, 01:56:48 PM » |
|
Cameyo isn't that great. Although for your eye the app you have 'Cameyo'ed' stores everything in the same location, it does create a VOS folder in your user's data folder with a lot of info in there. Understandable, as it will make functioning of 'cameyo'ed' applications a lot easier. However, don't be completely "fooled" by the concept that everything is really stored in one folder only.
Don't know about other, similar to Cameyo applications, so no comment there.
4wd's post above is spot on, that is the best way to go.
|
|
|
|
|
Logged
|
|
|
|
|
