SyntaxBomb - Indie Coders

Quote from: Aurel on May 22, 2021, 20:13:46
Do i really need to repeat myself
One of option is to build source + runtime ..called binder.
BUT if the runtime core is too multiplatform then is not easy to create binder...
well many users..yeah ..many ...
where are those many ?

You are talking about tacking on an sb app at the bottom of an sb.exe program much simpler to get the sb.exe and run all the apps you like from it, think of all the space you save if you have more than one app.
And suppose the app requires additional files, still have to pack them up with distro anyway.

It's like building a mansion for a dog.

No is not ...
It is most elegant way to run interpreted programs and whole bunch of windows
software work on similar way,many interpreted languages from basic mindteq list can do that .

Quote from: Aurel on May 26, 2021, 06:54:03
No is not ...
It is most elegant way to run interpreted programs and whole bunch of windows
software work on similar way,many interpreted languages from basic mindteq list can do that .

QuoteNo it is not...

"elegant"

It is literally tacky!

But maybe we should define elegance, otherwise we just throw our opinions at each other.

My definition of elegance is doing a job with the least amount of work and complication.

Tacking on an app at the end of an exe is just allot silly work, just run the app through the interpreter and distribute the interpreter with a ton of apps, you can also update app without having to tack it onto another exe.

..and how is not
when you bind your source to interpreter runtime you get one compact exe.
and what you see problematic there ?
On this way ther are some comercial program made.

Quote from: bplus on May 26, 2021, 17:49:07

Quote from: Aurel on May 26, 2021, 06:54:03
No is not ...
It is most elegant way to run interpreted programs and whole bunch of windows
software work on similar way,many interpreted languages from basic mindteq list can do that .

QuoteNo it is not...

"elegant"

It is literally tacky!

But maybe we should define elegance, otherwise we just throw our opinions at each other.

My definition of elegance is doing a job with the least amount of work and complication.

Tacking on an app at the end of an exe is just allot silly work, just run the app through the interpreter and distribute the interpreter with a ton of apps, you can also update app without having to tack it onto another exe.

But surely, for the user, having to install an interpreter program and then run the app through it is more work and complication than just getting an exe that they run in the usual way, possibly just unzipping it to a folder.

of course it is better, imagine how many people on windows know how to use interpreter ,editor ..
another option ..maybe pack runtime with source ,then when user run runtime.exe then that runtime
load source and execute it ,
OR use .bat file ...
.OR use maybe some packer with autorun feature...
but all that are just ideas ...author must decide ...

Quote from: Aurel on May 26, 2021, 21:19:05
of course it is better, imagine how many people on windows know how to use interpreter ,editor ..
another option ..maybe pack runtime with source ,then when user run runtime.exe then that runtime
load source and execute it ,
OR use .bat file ...
.OR use maybe some packer with autorun feature...
but all that are just ideas ...author must decide ...

OK get started. Show me.

There are a few different applications for building installation programs:

https://en.wikipedia.org/wiki/List_of_installation_software

I've previously used NSIS but it looks like "Inno Setup' is fairly popular. Alternatively, I recently found this:

https://pakkly.com/

So basically you'd use one of these tools to build an single installer program. Running this would copy all of your application files into "Program Files" or where ever and then setup a menu entry ready to go.

For a SmallBASIC project, your application files would need to include sbasic.exe and perhaps some module dll's. I'm okay with anyone re-distributing these. Note that sbasicg and sbasici are not ideal for this use-case. I would be great to see something made with the raylib module.

Quote from: chrisws on May 28, 2021, 23:51:31
For a SmallBASIC project, your application files would need to include sbasic.exe and perhaps some module dll's. I'm okay with anyone re-distributing these. Note that sbasicg and sbasici are not ideal for this use-case. I would be great to see something made with the raylib module.

Hello, by the way, I have a question about another thing.

Now there are two versions of SmallBASIC: sbasic.exe(console version) and sbasicg.exe(SDL version). All the current dll module files are used with sbasic.exe. I want to ask a question. Can the SDL features inside the sbasicg.exe file be packed into a dll module file as well? If it is possible for you to pack the SDL features into a dll module file, SmallBASIC users can therefore use the sbasic.exe file with this new SDL dll module file in the future. As a result, sbasicg.exe will not be needed anymore in the future. You only need to make the sbasic.exe file for the next version of SmallBASIC. More convenient for you. Moreover, users will not be confused any more.

i think that is not possible to compile SDL library with sbasic.exe...
only if SDL exists as static library then you can compile it into one compact exe.
Hmm that is a problem ..i forget that sbasic depend on SDL ..
well then yes only solution would be packer ...but one
let say which compile (pack ) all files into one coompressed exe
like UPX do.

Quote from: Aurel on May 29, 2021, 07:17:59
i think that is not possible to compile SDL library with sbasic.exe...
only if SDL exists as static library then you can compile it into one compact exe.
Hmm that is a problem ..i forget that sbasic depend on SDL ..
well then yes only solution would be packer ...but one
let say which compile (pack ) all files into one coompressed exe
like UPX do.

The core code is just plain c with minimal dependencies. There's a bunch of UI code which depends on an internal interface.

Then the FLTK, SDL or Android versions depend on the internal interface.  This design is known as "dependency inversion".

So there could be a DLL which incorporates some of this UI code. It can all be statically linked.

Quote from: chrisws on May 29, 2021, 08:03:09


The core code is just plain c with minimal dependencies. There's a bunch of UI code which depends on an internal interface.

Then the FLTK, SDL or Android versions depend on the internal interface.  This design is known as "dependency inversion".

So there could be a DLL which incorporates some of this UI code. It can all be statically linked.

So you meant that it was possible? Will you plan to make the SDL dll module?

Quote from: chrisws on May 19, 2021, 10:46:13
In the console version you can pass the -x option

$ sbasic -x foo.bas

This will run foo.bas and also produce foo.sbx

Now you can run:

$ sbasic foo.sbx

sbasicg -r foo.sbx
works too, for programs with graphics
didn't try on android, would be nice if it does - on android the prog doesn't regognize the extension
just a remark, the quoted strings are NOT scrambled and after editing the code still runs.
possible to fix?
cheers

Quote from: jsalai on June 08, 2021, 22:23:03

sbasicg -r foo.sbx
works too, for programs with graphics

It is an astonishing discovery.

Quote
- on android the prog doesn't regognize the extension
just a remark, the quoted strings are NOT scrambled and after editing the code still runs.
possible to fix?

Perhaps only 'chrisws' is able to solve your problem. You need to wait for the help from 'chrisws'. Actually, I am not a real user of SmallBASIC. I am an curious observer of SmallBASIC.

Quote
cheers

Welcome to the forum!

Quote from: round157 on June 11, 2021, 08:47:34

Welcome to the forum!

Thanks for your kind welcome post!

Quote
Perhaps only 'chrisws' is able to solve your problem. You need to wait for the help from 'chrisws'. Actually, I am not a real user of SmallBASIC. I am an curious observer of SmallBASIC.

Of course, although it is not a BIG problem, more an accurate observation.
On the other side I assumed, the "junior member" 'chrisws', is the real "administrator" of this small section dedicated to SmallBASIC, so I quoted his message.

And recently here was a discussion about the "old/new" name of the SmallBASIC, mu proposal would be:
VeryLargeBASIC, leaving the SMALL attribute to M$.

Thanks again, and take care... The stupidity conquers the World!