Re: Dgame RC #1
On Thursday, 2 April 2015 at 02:36:52 UTC, Craig Dillabaugh wrote:
On Wednesday, 1 April 2015 at 18:30:01 UTC, Namespace wrote:
Since the weekend Dgame went into the release phase:
https://github.com/Dgame/Dgame/releases/tag/v0.5.0-rc.1
http://dgame-dev.de/?page=download
The Website (http://dgame-dev.de/) is fully updated and
should be useable on every device. Please let me know if you
noticed unexpected behavior (at Dgame or on the website).
I also want to participate on "one game a month
(http://www.onegameamonth.com/). I hope you will vote for me
there. ;)
I'm sure that will bring some new light to the D community and
it will be a good stress test for Dgame.
Hi. I tried to build the first tutorial example from the Dgame
website. It builds fine, but I get the following error when
attempting to run.
./game1
derelict.util.exception.SymbolLoadException@../../../.dub/packages/derelict-util-1.9.1/source/derelict/util/exception.d(35):
Failed to load symbol SDL_HasAVX from shared library libSDL2.so
ldd game1
linux-vdso.so.1 (0x7fff25d89000)
libdl.so.2 => /lib64/libdl.so.2 (0x7f8517616000)
libpthread.so.0 => /lib64/libpthread.so.0
(0x7f85173f8000)
libm.so.6 => /lib64/libm.so.6 (0x7f85170f5000)
librt.so.1 => /lib64/librt.so.1 (0x7f8516eed000)
libc.so.6 => /lib64/libc.so.6 (0x7f8516b3f000)
/lib64/ld-linux-x86-64.so.2 (0x7f851781a000)
libSDL2.so is in /usr/lib64 but I copied it to the game1
directory for good measure, but it still couldn't run.
System is 64-bit OpenSuse 13.3
uname -a
Linux linux-qlhb.site 3.11.10-25-desktop #1 SMP PREEMPT Wed Dec
17 17:57:03 UTC 2014 (8210f77) x86_64 x86_64 x86_64 GNU/Linux
My dub.json file (dub version 0.9.22)
{
"name": "game1",
"description": "My first dgame attempt.",
"copyright": "Copyright © 2015, Craig Dillabaugh",
"authors": ["Craig Dillabaugh"],
"dependencies": {
"dgame": ">=0.5.0-rc.1"
}
}
Any tips on how to correct this would be appreciated.
Just a follow up comment. Apparently the instructions for
installing all libraries at once in the tutorial don't work for
OpenSuse. So I couldn't just install the SDL library but had to
install the other libraries individually:
So just in case there are any other OpenSuse users out there
(note, I suppose I didn't need the devel version of libSDL2 ...):
sudo zypper in libSDL2-devel
sudo zypper in libSDL2_image-2_0-0
sudo zypper in libSDL2_mixer-2_0-0
sudo zypper in libSDL2_ttf-2_0-0
Unfortunately libSDL2_mixer-2_0-0 install keeps failing because
the OpenSuse repositories don't seem to have the file, weird! I
don't know if that is the source of my troubles but may have to
build SDL form scratch. Anyway, I have to get some sleep but I
will try building SDL myself and see if that can fix things.
Craig
Re: Dgame RC #1
On Wednesday, 1 April 2015 at 18:30:01 UTC, Namespace wrote:
Since the weekend Dgame went into the release phase:
https://github.com/Dgame/Dgame/releases/tag/v0.5.0-rc.1
http://dgame-dev.de/?page=download
The Website (http://dgame-dev.de/) is fully updated and should
be useable on every device. Please let me know if you noticed
unexpected behavior (at Dgame or on the website).
I also want to participate on "one game a month
(http://www.onegameamonth.com/). I hope you will vote for me
there. ;)
I'm sure that will bring some new light to the D community and
it will be a good stress test for Dgame.
Hi. I tried to build the first tutorial example from the Dgame
website. It builds fine, but I get the following error when
attempting to run.
./game1
derelict.util.exception.SymbolLoadException@../../../.dub/packages/derelict-util-1.9.1/source/derelict/util/exception.d(35):
Failed to load symbol SDL_HasAVX from shared library libSDL2.so
ldd game1
linux-vdso.so.1 (0x7fff25d89000)
libdl.so.2 => /lib64/libdl.so.2 (0x7f8517616000)
libpthread.so.0 => /lib64/libpthread.so.0
(0x7f85173f8000)
libm.so.6 => /lib64/libm.so.6 (0x7f85170f5000)
librt.so.1 => /lib64/librt.so.1 (0x7f8516eed000)
libc.so.6 => /lib64/libc.so.6 (0x7f8516b3f000)
/lib64/ld-linux-x86-64.so.2 (0x7f851781a000)
libSDL2.so is in /usr/lib64 but I copied it to the game1
directory for good measure, but it still couldn't run.
System is 64-bit OpenSuse 13.3
uname -a
Linux linux-qlhb.site 3.11.10-25-desktop #1 SMP PREEMPT Wed Dec
17 17:57:03 UTC 2014 (8210f77) x86_64 x86_64 x86_64 GNU/Linux
My dub.json file (dub version 0.9.22)
{
"name": "game1",
"description": "My first dgame attempt.",
"copyright": "Copyright © 2015, Craig Dillabaugh",
"authors": ["Craig Dillabaugh"],
"dependencies": {
"dgame": ">=0.5.0-rc.1"
}
}
Any tips on how to correct this would be appreciated.
Re: dsq-1: open-source software synthesizer
On 2/04/2015 8:42 a.m., Joseph Rushton Wakeling wrote: On Monday, 30 March 2015 at 05:23:18 UTC, Rikki Cattermole wrote: This is a primarily a french license. It took me a good while to understand that it was compatible with e.g. MIT. Compatible in what way? Isn't CeCILL a copyleft license? (It's not 100% obvious to me whether strong or weak copyleft is implied, because their definition of an 'External Module' is unclear: I'm not sure if something is rendered non-external by linking, or merely by static linking, or something else again.) As far as I remember, it should just be ok. The only real issue is with lgpl ext. But again, you can see why I want this clarified.
Re: Dgame RC #1
On Wednesday, 1 April 2015 at 18:30:01 UTC, Namespace wrote: Since the weekend Dgame went into the release phase: https://github.com/Dgame/Dgame/releases/tag/v0.5.0-rc.1 http://dgame-dev.de/?page=download The Website (http://dgame-dev.de/) is fully updated and should be useable on every device. Please let me know if you noticed unexpected behavior (at Dgame or on the website). I also want to participate on "one game a month (http://www.onegameamonth.com/). I hope you will vote for me there. ;) I'm sure that will bring some new light to the D community and it will be a good stress test for Dgame. Great work! I'm really enjoying using Dgame at the moment and it makes a really nice change from all the embedded C++ I have to do at work. I'll make sure to go and vote too :) Cheers, stew
Re: dsq-1: open-source software synthesizer
On Monday, 30 March 2015 at 05:23:18 UTC, Rikki Cattermole wrote: This is a primarily a french license. It took me a good while to understand that it was compatible with e.g. MIT. Compatible in what way? Isn't CeCILL a copyleft license? (It's not 100% obvious to me whether strong or weak copyleft is implied, because their definition of an 'External Module' is unclear: I'm not sure if something is rendered non-external by linking, or merely by static linking, or something else again.)
Re: dsq-1: open-source software synthesizer
2015-04-01 13:54 GMT+02:00 Rikki Cattermole via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com>: > > There are more types of abstractions than just classes vs interfaces. What > goes into a module for example is a prime example of an abstraction. A > purpose. > > Which also have it's problem. For example, most symbols in vibe.internal are public. That's because we didn't have `package(identifier)` (and we still don't have, since we're supporting 2.065).
Re: Dgame RC #1
On Wednesday, 1 April 2015 at 18:30:01 UTC, Namespace wrote: Since the weekend Dgame went into the release phase: https://github.com/Dgame/Dgame/releases/tag/v0.5.0-rc.1 http://dgame-dev.de/?page=download The Website (http://dgame-dev.de/) is fully updated and should be useable on every device. Please let me know if you noticed unexpected behavior (at Dgame or on the website). I also want to participate on "one game a month (http://www.onegameamonth.com/). I hope you will vote for me there. ;) I'm sure that will bring some new light to the D community and it will be a good stress test for Dgame. Looks nice. I've never done any real game programming, but I told my kids that we should try to design some simple games together (since I want to get them interested in coding). I am going to give Dgame a try. Thanks for making this available. Craig
Dgame RC #1
Since the weekend Dgame went into the release phase: https://github.com/Dgame/Dgame/releases/tag/v0.5.0-rc.1 http://dgame-dev.de/?page=download The Website (http://dgame-dev.de/) is fully updated and should be useable on every device. Please let me know if you noticed unexpected behavior (at Dgame or on the website). I also want to participate on "one game a month (http://www.onegameamonth.com/). I hope you will vote for me there. ;) I'm sure that will bring some new light to the D community and it will be a good stress test for Dgame.
Re: dsq-1: open-source software synthesizer
On Thu, 02 Apr 2015 00:54:52 +1300, Rikki Cattermole wrote: > There are more types of abstractions than just classes vs interfaces. > What goes into a module for example is a prime example of an > abstraction. A purpose. it's even harder, as i sometimes has troubles deciding what should go into a function... signature.asc Description: PGP signature
Re: dsq-1: open-source software synthesizer
On 1/04/2015 11:07 p.m., Sönke Ludwig wrote: Am 01.04.2015 um 11:33 schrieb Rikki Cattermole: On 1/04/2015 10:28 p.m., Sönke Ludwig wrote: Am 30.03.2015 um 08:34 schrieb Rikki Cattermole: snip Yeah, the vibe.d/dub guys are amazing at getting stuff working. But horrible at abstraction's especially with library code. Okay. Nobody can be the best at everything. So it was a compliment :) You've done an excellent job with them. And by the looks of things, you are now splitting up e.g. vibe.d So again its mostly past tense observation on that front. I'm kinda the opposite. Great at abstractions. Horrible at getting the damn thing working. I personally usually stay away from using overly strong terms like "horrible" for online conversations, because it's just far too likely that someone gets offended (I'm usually a fan of good irony for example, but almost never use it online). I agree, I was quite extreme. In reality we're only talking in shades of grey with a difference of maybe 5 (0 .. 255). There is a reason why most people IRL think I'm a jerk. Always take stuff like this with a grain of salt. It's only meant to make people think about the subject, not as a factoid. On topic, I don't think that splitting up the library or not does necessarily have anything to do with abstraction. The library is built in a modular way, so that splitting it up mainly just becomes an issue of the build configuration. If you have other examples of where you think the abstractions are lacking, I'd be interested to know of course. If I was to start doing it, Vibe.d would be next to useless. No you guys are doing a wonderful job. I really can't stress that enough. I generally value good abstraction as important, but that doesn't always mean that the most extreme abstraction is the best one. Abstraction comes at the cost of added complexity (on the library side, but more importantly on the user side) and sometimes at the cost of performance, so it's always a trade-off. There are more types of abstractions than just classes vs interfaces. What goes into a module for example is a prime example of an abstraction. A purpose.
Re: dsq-1: open-source software synthesizer
Am 01.04.2015 um 11:33 schrieb Rikki Cattermole: On 1/04/2015 10:28 p.m., Sönke Ludwig wrote: Am 30.03.2015 um 08:34 schrieb Rikki Cattermole: snip Yeah, the vibe.d/dub guys are amazing at getting stuff working. But horrible at abstraction's especially with library code. Okay. Nobody can be the best at everything. So it was a compliment :) You've done an excellent job with them. And by the looks of things, you are now splitting up e.g. vibe.d So again its mostly past tense observation on that front. I'm kinda the opposite. Great at abstractions. Horrible at getting the damn thing working. I personally usually stay away from using overly strong terms like "horrible" for online conversations, because it's just far too likely that someone gets offended (I'm usually a fan of good irony for example, but almost never use it online). On topic, I don't think that splitting up the library or not does necessarily have anything to do with abstraction. The library is built in a modular way, so that splitting it up mainly just becomes an issue of the build configuration. If you have other examples of where you think the abstractions are lacking, I'd be interested to know of course. I generally value good abstraction as important, but that doesn't always mean that the most extreme abstraction is the best one. Abstraction comes at the cost of added complexity (on the library side, but more importantly on the user side) and sometimes at the cost of performance, so it's always a trade-off.
Re: dsq-1: open-source software synthesizer
Am 01.04.2015 um 11:32 schrieb ketmar:
On Wed, 01 Apr 2015 11:28:12 +0200, Sönke Ludwig wrote:
You can actually use DUB as a library without any issues (within the DUB
eco system, just add it as a dependency, otherwise drop the app.d file
when building). The API is still not ideal (missing some documentation
and needs some cleanup), because it has grown by contribution from
multiple people and a public API hasn't been a primary goal at the time.
i have concerns about API stability, though. it's always better to have
"officially announced" library with some guarantees ("we will break API
on each release" is good too ;-).
This will happen soon, when it's ready for the 1.0.0 release. It'll then
be subject to the usual SemVer guarantees.
Re: dsq-1: open-source software synthesizer
On 1/04/2015 10:28 p.m., Sönke Ludwig wrote: Am 30.03.2015 um 08:34 schrieb Rikki Cattermole: snip Yeah, the vibe.d/dub guys are amazing at getting stuff working. But horrible at abstraction's especially with library code. Okay. Nobody can be the best at everything. So it was a compliment :) You've done an excellent job with them. And by the looks of things, you are now splitting up e.g. vibe.d So again its mostly past tense observation on that front. I'm kinda the opposite. Great at abstractions. Horrible at getting the damn thing working.
Re: dsq-1: open-source software synthesizer
On Wed, 01 Apr 2015 11:28:12 +0200, Sönke Ludwig wrote:
> You can actually use DUB as a library without any issues (within the DUB
> eco system, just add it as a dependency, otherwise drop the app.d file
> when building). The API is still not ideal (missing some documentation
> and needs some cleanup), because it has grown by contribution from
> multiple people and a public API hasn't been a primary goal at the time.
i have concerns about API stability, though. it's always better to have
"officially announced" library with some guarantees ("we will break API
on each release" is good too ;-).
signature.asc
Description: PGP signature
Re: dsq-1: open-source software synthesizer
Am 30.03.2015 um 08:34 schrieb Rikki Cattermole: On 30/03/2015 7:26 p.m., ketmar wrote: what i really want to have is "libdub". i.e. turning dub to library, so it can be easily integrated in any D project (rdmd comes to mind first). i don't want D building abilities, for example, but i really like to use it's package management part (and get list of files and compiler flags for that packages). sure, i can do this by parsing dub jsons and execing dub itself to do package management work, but libdub is better... maybe someday i'll wrote such thing. ;-) You can actually use DUB as a library without any issues (within the DUB eco system, just add it as a dependency, otherwise drop the app.d file when building). The API is still not ideal (missing some documentation and needs some cleanup), because it has grown by contribution from multiple people and a public API hasn't been a primary goal at the time. Yeah, the vibe.d/dub guys are amazing at getting stuff working. But horrible at abstraction's especially with library code. Okay.
Re: foxyproxyvideoutility - problem
Nice post.
