Re: Re: [tsc-devel] Rewrite: Programming language
by rymg19＠gmail.com
Wait, is writing the game in Go up in the air????
Oh god...
--
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone
elsehttp://refi64.com
On Sep 25, 2017 at 6:57 AM, <Marvin Gülker <m-guelker(a)phoenixmail.de>>
wrote:
Hi,
I have further investigated Go and am positively surprised. The
integration with existing C libraries is the easiest one I have seen
until now. cgo (the tool used for it, ships with Go itself) is able to
parse C header files fully automatically. Add
/*
#include <your/header/here.h>
#include <stdlib.h>
...
*/
import "C"
to your Go file and you can directly (!) use the C functions in the
named headers without having to write mapping functions for the most
part. Only some edge cases require you to write C code (most notably
accessing members of unions, though some raw byte magic in Go could work
around that). cgo is even able to parse simple macros and transform them
into a Go equivalent.
It is not possible to integrate C++ (or any other language) directly. It
however is possible to bridge to a C++ or other language library via a C
interface; in this regard, Go is not different from Ruby.
Am 24. September 2017 um 15:09 Uhr +0300 schrieb Lauri Ojansivu <x(a)xet7.org>:
> I have programmed with Go about 3 months previously, and it's really
> nice.
Okay, this sounds good. I find it easier to work with than C++, though
it feels a little like writing object-oriented code in C, because one
has to mention the receiver explicitely in a method. The "backward" type
notation needs some accustomisation, I am still making this mistake
again and again. One thing I specifically dislike about Go's syntax is
the forced curly else clause, as in the following:
if ... {
} else { // << `else' cannot be on its own line
...
}
This bogs me. When I work on `if/else' I mentally draw a straight line
up the code to find the matching `if' and the curled braces confuses me,
which is worse especially with long `if/elseif/else'
statements. Luckily, there is a remedy for the latter: a bare `switch'
statement. For `else' alone, I can live with it. The language was not
made specifically for me after all.
> It compiles very fast, and can crosscompile fast to Windows, ARM etc very
> nicely from Linux etc.
I have not tested crosscompilation yet, but I believe you if you say it
works. I will take a look on it later on. What I did test was native use
of Go on Windows, and I am satisfied by what I found. Go works
flawlessly with MSYS2, it even is contained in the standard
repositories. cgo works as well, and it has no problems linking to a
C library compiled with MSYS2's gcc; I have not yet tested the Win32API,
but if it can link to normal libraries, I see no reason why it should
not be able to work with the Win32API.
For my tests, I wrote a simple Pong game in Go that uses Allegro[1]. The
game is available on GitHub[2] and compiles as-is both on Linux and on
Windows using a standard `go build'. The game is not a beaty in code
organisation and has problems if you have a good graphics card, because
the ball moves with 1px per frame (i.e. the faster your graphics card,
the faster the game). But it's not a serious game anyway, so I did not
feel like fixing those problems, it's goal is to demonstrate
cross-platform use of Go with a C library linked.
Greetings
Marvin
[1]: http://liballeg.org
[2]: https://github.com/Quintus/gopong
--
Blog: https://www.guelkerdev.de
PGP/GPG ID: F1D8799FBCC8BC4F
1 year, 10 months
Rewrite: Programming language
by Marvin Gülker
Hi everyone,
as I promised in my earlier email, here is another message on the
rewrite topic. I am currently evaluating possible programming
languages. C++ surely is a proven language and definitely remains the
fallback option if I don't find something suitable, but its verbosity
(header files!), its inability to easily work with Unicode, and its
overall usability have made me think that it might be time to look for
alternatives. I have made a list of criteria that the language has to
fullfill:
1. A syntax without a large amount of syntactical complexity like C++
has, and I have to like the "feel" of the language,
2. No header files,
3. The language should exist for some time and have a perspective into
the future, as well as an established community (I do not want to
use a language that's gone in five years because it's not "hip"
anymore),
4. Compiled language, i.e. no interpreted language and no VM language,
5. Easy use of existing C libraries (including Win32API), bonus
if C++ libraries can be used,
6. Rich standard library so that using it does not create a plethora of
dependencies where not required,
7. Stable API of the language and its standard library, no
breaking releases of it all the time,
8. Unicode support without external dependencies,
9. Usability on Windows without propriatary MSVC required, bonus if
it can crosscompile to Windows from Linux,
10. Usability on Linux,
11. Not purely functional language.
There's some personal taste in this criteria, and some definite need. If
you think more or less criteria are required, feel free to speak up.
I have been evaluating programming languages during the last days. These
are my results so far, in no peculiar order:
* Rust: While I am willing to accept that it meets criterion 3 above by
now due Mozilla's use of it in Firefox, it does not meet criterion
6. It has this web developer taste of having external dependencies for
every small thing downloaded from the web -- for example, no rand()
function without an external dependency. It should be distros
providing libraries. It also has problems with criterion 7 as
far as I can see.
* C#: Fails on 4, 9, and currently still 10, until .NET Core has been
completed fully for Linux as well.
* Java: Fails on 4, and I don't want it.
* D: I originally thought this is a hot candidate, until I discovered it
utterly fails on 9, and quite a bit on 5 if your C library on Windows
is not compiled with MSVC,
* Go: I am in the process of evaluating it. Looks like it may fulfill
all the criteria, but I am not finished with it yet. Especially I have
not tested its usability on Windows yet.
What made me first not consider Go was that it does not provide
inheritance, but once I discovered that Rust does neither, I opened my
mind on the topic a little. Its interfaces actually look promising. I
will further evaluate the language and give feedback here.
Marvin
--
Blog: https://www.guelkerdev.de
PGP/GPG ID: F1D8799FBCC8BC4F
1 year, 11 months
Re: Re: [tsc-devel] On the Continuation of TSC
by rymg19＠gmail.com
Hmmm... hosting there might work. Who's your hosting provider so I can
check the bandwith restrictions?
(I mean, considering the project activity, I don't see us going over the
limit anytime soon...)
--
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone
elsehttp://refi64.com
On Sep 20, 2017 at 7:43 PM, <Sydney Dykstra <sydneyjd(a)openmailbox.org>>
wrote:
I would like to see this project thrive, as we all would, but I am not
in a personal position to start doing major things for the project, and
I also don't know a great deal about coding.
Either way, whatever happens I will back up this project (unless
someone does something major I don't agree with, of course, but I don't
see that happening any time too soon) and help out where I can, as I
have been in the past.
Re: Ryan, I'm not sure if there any bandwidth limitations that we can
excede with the Project's server, but I don't see why we couldn't host
the Appimages on it. If that is not doable, I might be able to host them
on my personal VPS, but I am limited to 1TB of bandwidth per year, so we
would have to make them weekly or something. Or I could pay for more
bandwidth... that always fixes things. I also only have about 5GB of
free HDD space left. But it would work.
-Sydney
On 09/20/2017 06:16 PM, rymg19(a)gmail.com wrote:
> FWIW I *have* been doing some work on trying to make AppImages, though I
> got stuck at finding a hosting provider that would handle ~200MB
> Travis-generated images...
>
>
> --
> Ryan (ライアン)
> Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
> http://refi64.com
>
>> On Sep 20, 2017 at 9:47 AM, <Marvin Gülker
>> <mailto:m-guelker@phoenixmail.de>> wrote:
>>
>> Hi everyone,
>>
>>
>>
>> since I retired from the lead position, there has not been much move in
>>
>> TSC's development; taking a look at `$ git log' for `devel' proofs
>>
>> that. xet7 and I have recently met in Finland (physically) and have
>>
>> spoken about the matter; in that, xet7 outlined that his main focus is
>>
>> -- rightly, as he commercially uses it -- on Wekan. kirbyfan has assumed
>>
>> the position as assistant lead, but that was about it (no offense; I
>>
>> know this is free time).
>>
>>
>>
>> During the last months, I have observed what happens around TSC when I
>>
>> abstain from it mostly, and found that it wasn't much. This inevitably
>>
>> must lead to the project's death.
>>
>>
>>
>> This finding entitles me to make a suggestion. I cannot and will not
>>
>> return to work on TSC as intensly as I did earlier, for my studies have
>>
>> taken over most of my time. I however intend to do *something*, which is
>>
>> more in any case than what has happened here in the last months. I have
>>
>> often enough made my position towards the current codebase clear and
>>
>> have been met with opposition by people who are now not working on
>>
>> materialising their view of TSC. I feel the desire to experiment with
>>
>> something new. My suggestion is that therefore, I will start the
>>
>> previously mentioned rewrite. I invite everyone to join or to oppose,
>>
>> but in order to have a word in the decisions made in that rewrite I
>>
>> think you should actually contribute to it in the part you want to
>>
>> decide something on[1].
>>
>>
>>
>> Someone is going to point out that this is fruitless effort, as I don't
>>
>> have the time I used to have and a rewrite takes time. Surely this
>>
>> person is correct, but this is not the entire story. If I don't do the
>>
>> rewrite, I won't work on the current state of TSC either because --
>>
>> sorry -- I don't feel like doing so; it is my hobby free time after
>>
>> all. Thus, nobody would work on it. This would be fruitless as well. TSC
>>
>> is not meant to fulfill any kind of commercial requirement; the coding
>>
>> on it should be hobby, thus fun and goal in itself.
>>
>>
>>
>> I want to blow some fresh air into the stalled development. Accept the
>>
>> rewrite as a baseline, come and sit down with me scatching how the new
>>
>> TSC should be coded. If you don't want, I will fork.
>>
>>
>>
>> Marvin
>>
>>
>>
>> [1] Personally, I have come to the conclusion that the Voting Rules are
>>
>> too formal for a small project. The idea of a law student in early
>>
>> semestres. We should abandon them in favour of the mentioned approach;
>>
>> if you want it formally, we can vote on the abondonment of the Voting
>>
>> Rules (which would require a 2/3 majority as outlined in the Voting
>>
>> Rules).
>>
>>
>>
>> --
>>
>> Blog: https://www.guelkerdev.de
>>
>> PGP/GPG ID: F1D8799FBCC8BC4F
>>
>>
>>
1 year, 11 months
Re: [tsc-devel] On the Continuation of TSC
by rymg19＠gmail.com
FWIW I *have* been doing some work on trying to make AppImages, though I
got stuck at finding a hosting provider that would handle ~200MB
Travis-generated images...
--
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone
elsehttp://refi64.com
On Sep 20, 2017 at 9:47 AM, <Marvin Gülker <m-guelker(a)phoenixmail.de>>
wrote:
Hi everyone,
since I retired from the lead position, there has not been much move in
TSC's development; taking a look at `$ git log' for `devel' proofs
that. xet7 and I have recently met in Finland (physically) and have
spoken about the matter; in that, xet7 outlined that his main focus is
-- rightly, as he commercially uses it -- on Wekan. kirbyfan has assumed
the position as assistant lead, but that was about it (no offense; I
know this is free time).
During the last months, I have observed what happens around TSC when I
abstain from it mostly, and found that it wasn't much. This inevitably
must lead to the project's death.
This finding entitles me to make a suggestion. I cannot and will not
return to work on TSC as intensly as I did earlier, for my studies have
taken over most of my time. I however intend to do *something*, which is
more in any case than what has happened here in the last months. I have
often enough made my position towards the current codebase clear and
have been met with opposition by people who are now not working on
materialising their view of TSC. I feel the desire to experiment with
something new. My suggestion is that therefore, I will start the
previously mentioned rewrite. I invite everyone to join or to oppose,
but in order to have a word in the decisions made in that rewrite I
think you should actually contribute to it in the part you want to
decide something on[1].
Someone is going to point out that this is fruitless effort, as I don't
have the time I used to have and a rewrite takes time. Surely this
person is correct, but this is not the entire story. If I don't do the
rewrite, I won't work on the current state of TSC either because --
sorry -- I don't feel like doing so; it is my hobby free time after
all. Thus, nobody would work on it. This would be fruitless as well. TSC
is not meant to fulfill any kind of commercial requirement; the coding
on it should be hobby, thus fun and goal in itself.
I want to blow some fresh air into the stalled development. Accept the
rewrite as a baseline, come and sit down with me scatching how the new
TSC should be coded. If you don't want, I will fork.
Marvin
[1] Personally, I have come to the conclusion that the Voting Rules are
too formal for a small project. The idea of a law student in early
semestres. We should abandon them in favour of the mentioned approach;
if you want it formally, we can vote on the abondonment of the Voting
Rules (which would require a 2/3 majority as outlined in the Voting
Rules).
--
Blog: https://www.guelkerdev.de
PGP/GPG ID: F1D8799FBCC8BC4F
1 year, 11 months
On the Continuation of TSC
by Marvin Gülker
Hi everyone,
since I retired from the lead position, there has not been much move in
TSC's development; taking a look at `$ git log' for `devel' proofs
that. xet7 and I have recently met in Finland (physically) and have
spoken about the matter; in that, xet7 outlined that his main focus is
-- rightly, as he commercially uses it -- on Wekan. kirbyfan has assumed
the position as assistant lead, but that was about it (no offense; I
know this is free time).
During the last months, I have observed what happens around TSC when I
abstain from it mostly, and found that it wasn't much. This inevitably
must lead to the project's death.
This finding entitles me to make a suggestion. I cannot and will not
return to work on TSC as intensly as I did earlier, for my studies have
taken over most of my time. I however intend to do *something*, which is
more in any case than what has happened here in the last months. I have
often enough made my position towards the current codebase clear and
have been met with opposition by people who are now not working on
materialising their view of TSC. I feel the desire to experiment with
something new. My suggestion is that therefore, I will start the
previously mentioned rewrite. I invite everyone to join or to oppose,
but in order to have a word in the decisions made in that rewrite I
think you should actually contribute to it in the part you want to
decide something on[1].
Someone is going to point out that this is fruitless effort, as I don't
have the time I used to have and a rewrite takes time. Surely this
person is correct, but this is not the entire story. If I don't do the
rewrite, I won't work on the current state of TSC either because --
sorry -- I don't feel like doing so; it is my hobby free time after
all. Thus, nobody would work on it. This would be fruitless as well. TSC
is not meant to fulfill any kind of commercial requirement; the coding
on it should be hobby, thus fun and goal in itself.
I want to blow some fresh air into the stalled development. Accept the
rewrite as a baseline, come and sit down with me scatching how the new
TSC should be coded. If you don't want, I will fork.
Marvin
[1] Personally, I have come to the conclusion that the Voting Rules are
too formal for a small project. The idea of a law student in early
semestres. We should abandon them in favour of the mentioned approach;
if you want it formally, we can vote on the abondonment of the Voting
Rules (which would require a 2/3 majority as outlined in the Voting
Rules).
--
Blog: https://www.guelkerdev.de
PGP/GPG ID: F1D8799FBCC8BC4F
1 year, 11 months