Re: Just found this debugger...
On Wednesday, 3 October 2018 at 13:08:50 UTC, Vladimir Panteleev wrote: On Wednesday, 3 October 2018 at 03:25:04 UTC, solidstate1991 wrote: and I don't want to go back to VisualD after VSCode for either a usable mago or VS native debug. Visual Studio makes a decent stand-alone source-level debugger. Just select the .exe file, and right-click it in the project/solution pane to start a debugging session. (Of course, you need to build with -m32mscoff or -m64 as well as -g). VisualD isn't even needed, though VS by itself won't understand D types like arrays/strings. I cannot find that option...
Re: My statements related to terminating my SAoC relationship
On Tuesday, 16 October 2018 at 02:20:09 UTC, Soulsbane wrote: Have you tried melatonin? My doctor has me take a 1mg tablet and split it in two. So I take 1/2 at bedtime. That is the sweet spot. If you take more than that you will end up groggy. No, but I'll since I used to have this issue even as a child, this might help. I'll ask my doctor again, if she doesn't help I'll just buy the ones that can be used without prescriptions. I hope it's not some melatonin insensitivity, that would require some pretty harsh drugs.
My statements related to terminating my SAoC relationship
I have done two mistakes: I underestimated the scope of the project and overestimated my capabilities. This caused a chain reaction, which in turn made the first milestone unreachable. At the same time, my sleep disorder became even worse. I started to sleep 10-12 hours a day while spending around 4-6 hours in bed just to trying to fall asleep, and since I had to do some housekeeping work it cut the planned 8 hours per day work down to 4-6 at most. I have taped off all the status indicator LEDs on my electronics, I asked my brother and father to refrain from loud TV watching at night, all for nothing. Caffeine intake don't worsen my ability of sleep. I do get tired, but somehow still don't feel myself sleepy. Tried to tell my doctors, but they just told me to do the stuff I've already done plus to refrain from using computers as much as possible and instead look for a job that don't require them. However, thanks to I had to use a "desk" with no leg room, my spine is all busted now, barely able to manage to lift 20kg without screaming in agony. I try to resume my work on improving mago, but on a much smaller scale and lower priority since I have to spend time finding a job, which is a very hard thing in this fascist country called Hungary, while also not supporting said fascist regime. While the state propaganda says there's a big shortage on workforce (to the point that supposedly humanitarians are being reeducated for Java developers), I also see a lot of people being rejected with bogus claims which tells me that there's something fishy, and hearing some controversies of political opponents' families suddenly losing their jobs says me that they're persecuting their political opponents at any means possible. Losing the funds put me in danger of homelessness, since I haven't been able to pay my father for rent and food for years, not to mention my PC is on its deathbed with its dried up CPU VRM capacitors, and USB and LAN ports fried after a thunderstorm and our previous ISP being skeptical with overvoltage protection (we got a direct hit into the antenna, which blew up his equipment, and fried by router, the LAN port, several USB ports, a cheap membrane keyboard, and a Logitech mouse I just have repaired). I think I'll take a few days of doing other stuff, since my sleeping disorder sabotaged my free time too and now I have to find a job, (preferably internship) to calm down a bit.
Just found this debugger...
I wanted to do some work on lzbacon (D port of lzham-codec with some extras such as tarball support), but without a debugger it's pretty hard (I suspect an error in the multithreading when looking up for a value, or some C++ language quirk I missed). The current state of mago-mi is nearly unusable with very limited command support, and I don't want to go back to VisualD after VSCode for either a usable mago or VS native debug. I couldn't find LLDB on my harddrive anymore, and GDB needs DWARF symbols. Then I had a thought: Is there anything usable on the market besides these? After I a quick Google search, I encountered with the "guy she told you to not to worry about": https://x64dbg.com/#start It seems it needs *.pdb files for symbols, which I'll test tomorrow, hopefully I don't have to cook something complicated for my family to waste my time. While I'm still encouraged to improve mago instead (I think alternatives are always a good option and the conversion will be finished by the weekend), maybe it'll be useful for some. Maybe I can use it for mago too.
Re: Quick C bindings
I would also like something, but for the C11 runtime, as it's essential for mago (uses it for unicode strings, rewriting them for Phobos would take too much time, and I've already ran out of time).
Will the core.stdc module be updated for newer versions of C?
While for the most part it still works very well, however when porting Mago I found a few functions that are not present in C99 (most notably wcsncpy_s). While I can write my own functions to do the same (already done this with C++'s array since a few classes inherited from std::vector, hopefully I don't need to fiddle too much with it on the Debug engine to limit reliance on GC) I think it would be a good idea to do some updates on the runtime library in this regard, especially as it's a very easily available @nogc library too.
Re: Looking for a mentor for SAoC
On Monday, 27 August 2018 at 20:47:08 UTC, Stefam Koch wrote: I guess I could help you out with coff. generating it is not the problem but linking it on windows currently requires the MS linker. which may not be desired. then again ... I think binutils do support coff as well. I might need you as a mentor. Currently I'm thinking out of the milestones, I probably can fully convert Mago to D by the end of September, in October I'll work on getting the COFF64 support at the same level as 32 bit ones, November and December will be spent with developing a GUI and bug fixes.
Re: D now has a dangerous competitor
On Tuesday, 28 August 2018 at 11:30:20 UTC, JN wrote: On Tuesday, 28 August 2018 at 08:39:20 UTC, bauss wrote: The following language is a dangerous competitor to D. https://github.com/joaomilho/Enterprise I often feel like this kind of 'jokes' are trying too hard. FizzBuzz Enterprise was fun when it first came out, and I know it's popular to hate on OOP programming, especially Java. But the fact is, a very big portion of software was built using OOP, and many of the hated design patterns have a place in programming. Sure, it doesn't provide witty one-liner quicksort examples, but when you have a group of people, having to integrate multiple webservices/databases, these kind of layered code architecture comes in handy. Of course sometimes people go too far, trying to make the code generic and fit every usecase, breaking YAGNI. Most of the hate towards OOP is misdirected. Java will be always slow because it always running in a VM, no structures so you have to rely on reference-type classes for everything. Other times it's on the developer. Thanks to my education, I first wanted to approach every problems in programming from an object-oriented viewpoint, since that was the only one we were taught (and I missed the classes on interfaces due to an incident, so I struggled to keep up). You have to learn where to use what. I personally hate C and C++ precompiler macros more, which made porting LZHAM to D a nightmare sometimes. Some parts of the macros got completely eliminated since Fiber saves most things on the stack.
Looking for a mentor for SAoC
I've chosen to work on Mago, with the following goals: -Porting it to D first and foremost to make code maintenance and expansion easier in the future. -Add better support for Win32-COFF (there's a few more bugs compared to Win32-OMF in my experience) and Win64-COFF. As I read COFF32 needs some manual installation, which will be made easier by either a Powershell script, or even a custom installer, the latter might branch out on its own project. -Fix some general bugs, like the non-working -break-insert -f. -Add some simple GUI for Mago-mi instead of just the GDB compatible text interface. -Make it to work better with LDC if possible. If I'll have time after the main milestones, I might add other functions besides the bug fixes, such as a memory editor, ability to debug programs and codes written in C and other languages for interoperability. Additionally you can help me to work on my college thesis. I still haven't chosen my subject matter, but it'll be either my graphics engine "PixelPerfectEngine", my compression library "lzbacon", or this if it's allowed. I need a mentor/consultant (the latter is what I got for the translation of the word "konzulens"), your main job is to help me out a bit.
Re: Weird bugs in DMD 2.81.0
Well, it seems I fixed the AA issue by removing a totally unrelated thing (an undoable event chain system, that got "deprecated"), but now I got another weird issue. Sometimes setting a dynamic array's length causes an access violation. Still only on WindowMaker, and nothing in PixelPerfectEditor. Does somebody have a foolproof method for designing window layouts without an editor? I starting to give up on this piece of crap software, however before that it took me a whole day to figure out where the elements should fall, then another day to debug issues with the layout. My current solution at this point is to type in stuff instead of relying on generated code.
Re: Weird bugs in DMD 2.81.0
On Saturday, 14 July 2018 at 07:01:59 UTC, Seb wrote: Any chance you can make a minimal, reproducible example of this? Would be great because then it can be put on bugzilla and other people can have a look at it too. I might try, but first I'll look at the functions to see if I can fix some of it by myself, fixing pointer overflows. I suspect that the drawing functions overflow due to small typos, once I mixed up the x and y coordinates of something then it resulted in a corrupted image.
Re: Weird bugs in DMD 2.81.0
On Saturday, 14 July 2018 at 00:58:08 UTC, solidstate1991 wrote: I found a temporary workaround. Basically I just save the content of the AA, then reapply it after the application's constructor finished, before that it always generated an exception when I tried to check its content e.g. via printing it to the screen. The program still crashes when I close it, and it seems like it's something GC related, which will be extremely hard to reproduce. I'm going to make a commit soon to Github (maybe even an alpha release), so people can check it out for themselves. The AA issue still happens when I disable the GC. What happens if I accidentally write into the memory space of an AA? Might be a pointer-overflow related issue I messed up, which will be a hell of a ride to find.
Re: Weird bugs in DMD 2.81.0
On Saturday, 7 July 2018 at 02:21:31 UTC, solidstate1991 wrote: I'll upload code tomorrow, but here's the premise: Sometimes elements disappear from associative arrays, causing all sorts of errors down the line, mostly access violations. My engine (PixelPerfectEngine) has a style sheet for its GUI, which generates basic values upon construction. This works mostly fine with PixelPerfectEditor, however WindowMaker crashes instantly when it needs to redraw anything. Both Mago and VS debugger were bit broken (first exception came from KernelBase.dll, then it only showed the caller of a getter function possibly caused the issue), but I managed to get enough information. The AA containing color indexes (ushort[string]) couldn't be accessed properly and when I tried the safe get method on it, a lot of values couldn't be accessed and later on a dynamic array had issues with access violation. I'm thinking on going back to 2.080.0 until this bug gets fixed. I found a temporary workaround. Basically I just save the content of the AA, then reapply it after the application's constructor finished, before that it always generated an exception when I tried to check its content e.g. via printing it to the screen. The program still crashes when I close it, and it seems like it's something GC related, which will be extremely hard to reproduce. I'm going to make a commit soon to Github (maybe even an alpha release), so people can check it out for themselves.
Re: Weird bugs in DMD 2.81.0
On Saturday, 7 July 2018 at 07:31:29 UTC, Seb wrote:
I'm sorry but without code there's not much we can do for you.
However, one thing we can try is to get your project on the
project tester once this regression is fixed.
https://github.com/ZILtoid1991/pixelperfectengine
Just did a commit recently. PixelPerfectEditor runs as it should
(unfinished, but most drawing algorithms work), under
WindowMaker, some stuff just disappear from AA.
Patching "PixelPerfectEngine.concrete.stylesheet"'s
StyleSheet.getColor to the following reveals that some elements
may have disappeared from the AA:
public ushort getColor(string colorName){
return color.get(colorName,0);
}
Also tested with an LDC, which is based on 2.80.1, and the same
anomaly still happens.
Re: How about implementing SPMD on SIMD for D?
On Saturday, 7 July 2018 at 13:20:53 UTC, Guillaume Piolat wrote: Oh yes, so much this. It would be very nice to have D_SIMD on DMD 32-bit. Does D_SIMD work on LDC?
Weird bugs in DMD 2.81.0
I'll upload code tomorrow, but here's the premise: Sometimes elements disappear from associative arrays, causing all sorts of errors down the line, mostly access violations. My engine (PixelPerfectEngine) has a style sheet for its GUI, which generates basic values upon construction. This works mostly fine with PixelPerfectEditor, however WindowMaker crashes instantly when it needs to redraw anything. Both Mago and VS debugger were bit broken (first exception came from KernelBase.dll, then it only showed the caller of a getter function possibly caused the issue), but I managed to get enough information. The AA containing color indexes (ushort[string]) couldn't be accessed properly and when I tried the safe get method on it, a lot of values couldn't be accessed and later on a dynamic array had issues with access violation. I'm thinking on going back to 2.080.0 until this bug gets fixed.
Re: How about implementing SPMD on SIMD for D?
I think fixing the SIMD support would be also great. 1) Make it compatible with Intel intrinsics. 2) Update it to work with AVX-512. 3) Add some preliminary support for ARM Neon. 4) Optional: Make SIMD to compile for all 32 bit targets, so I don't have to write long-ass assembly code for stuff. Once I even broke LDC with my code (see CPUblit).
Re: Replacing C's memcpy with a D implementation
On Sunday, 10 June 2018 at 12:49:31 UTC, Mike Franklin wrote:
void memcpyASM()
{
auto s = src.ptr;
auto d = dst.ptr;
size_t len = length;
asm pure nothrow @nogc
{
mov RSI, s;
mov RDI, d;
cld;
mov RCX, len;
rep;
movsb;
}
}
Protip: Use SSE or AVX for an even faster copying.
Looking for remote software development jobs using D
I have trouble getting any jobs in my homeland, since no local company hire any software developer (the closest would be some Linux sysadmin, if those jobs are still open), in my country most IT companies are web development only, and I'm not experienced enough with them (didn't want to learn at least 4 different badly designed languages for less money). I couldn't apply to other jobs since a catch 22 regarding my college status and local companies weren't interested in part-timers (the only way I could get a full-time job is if my college status is part-time, and I only can get a part-time college status if I get a full-time job first, the easiest way to bypass it is dropping out from college, get a job, then reapply to college and pray that you won't have to retake all classes). Unfortunately my family is getting into deeper and deeper financial troubles, I'm currently on the verge of dropping out (thanks to not being able to find an internship, and a consultant for my college thesis), and a minimum-wage job doesn't cover anything. About me: I'm working with D for 3 years, and I came from a Java background. I chose it as an alternative to C++, C#, and Java for a small project called VDP-engine (now called PixelPerfectEngine, available in dub). For a while I concentrated on Java and C# instead, however I came back for my engine and continued development on it. I also can code in C, C++, C#, PHP, however I'm not too experienced with the last one, my knowledge on HTML is only web 1.0 level at best, and I don't know any Javascript (besides of some pretty basic stuff coming from other languages). I'm specialized on software optimization, and have done some basic DSP and image processing stuff (see CPUblit in dub for the latter). I'm currently living in Hungary, but I'm planning to leave the country ASAP due to both economical and political reasons, the latter might be a possible reason why I couldn't get any kind of internship or job, however I don't have any evidence for that. I only speak English besides of Hungarian, but I'm planning on learning other languages thanks to Brexit. If I have to say how much money I would work for, then let it be $10/hour. However in my current situation, even less would be more than good. (I need money to replace aging and failing hardware, money to move out, etc)
Re: Is there some fast and @nogc capable binary search tree for D?
On Monday, 30 April 2018 at 02:43:44 UTC, 12345swordy wrote: If the data involved classes then the answer is no, as there is a bug regarding destroy as it involved external finalized c function. I'm writing a DIP draft that address this. I think I can get around that by storing the data in dynamic arrays for the while I need them, then use the tree for quicker random access.
Is there some fast and @nogc capable binary search tree for D?
Some components of my game engine would benefit from lookup trees. I tried to port one from Go, but either I messed up something bit that certain parts of the codes just won't execute for some reason, or the algorithm was poorly documented, and it will only optimize on one end of the binary search tree. Looked around on dub, couldn't find anything that wouldn't introduce too much new dependencies or that was actually @nogc capable. I would be interested in some preexisting one, or some better documented ones from the web. All I can find is either very basic theory or things that already work well in my implementation, like indexing and insertion without optimization.
Looking for internship and consulant for college thesis
I have problems finding a internship in my own country mostly due to lack of "experience" (time spent with working at any kind of workplace, even if it's working at a fast food restaurant), and without it I cannot get my college degree. My local area has no real IT jobs, or they look to employ a person full time who's more experienced with networking or Linux. I have multiple projects in D, PixelPerfectEngine (a 2D game engine made specifically to mimic retro aesthetics; link: https://github.com/ZILtoid1991/pixelperfectengine ), libPCM (ADPCM, Mu-Law, and A-Law algorithms; link: https://github.com/ZILtoid1991/libPCM ). There's two yet unpublished projects: CPUblit (image composing and drawing algorithms, currently awaits for testing of assembly lines) and libLZHAM (compression algorithm with LZMA-like ratios and near ZLib decompression speeds, full backwards compatibility with ZLib, soon I'll talk with the writer of the original algorithm if I can license my port under the Boost license). For my college thesis I planned to use my own game engine, but if somebody has some better idea for a project, then I can compromise with that.
Classinfo and @nogc conflict
I'm trying to speed up my graphic engine, however the presence of the GC in function Layer.updateRaster (see here: https://github.com/ZILtoid1991/pixelperfectengine/blob/master/pixelperfectengine/src/PixelPerfectEngine/graphics/layers.d ) means I get an occasional bump in CPU usage if not a framedrop (most performance related thing got fixed since then). I use classinfo for detecting the type of bitmaps, and while I probably will have a workaround for the associative array stuff, the classinfo thing is embedded into the runtime library, thus it needs to be fixed. I took a look at opEquals, but the trickier part would be making the toString function @nogc (make its return value a ref type?).
How hard would it be to get DMD to generate SIMD code for all x86 targets?
It would be also great if 32 bit and 64 bit long vector loading could be supported, so I don't have to write separate functions for that. Had to delete a lot of code I wrote in Assembly after I made a big mistake thanks to its much poorer readability compared to much more modern languages. If it's not a hard task, I might do it by myself.
Better vector support
I'm using vector operations in my graphics engine for rendering, since low-level raster operations in GPU are well hidden under layers of API, although I'm planning on porting the blitter algorithms for DCompute once it becomes more mature, as well as creating the CPUblit library for general use (will contain blitter and alpha-blending functions as well as basic drawing ones). However, since I have to write most of the functions with Assembly, I have to write every function multiple times in a hard-to-read format. After spending some time with using vectors, I came up with some suggestions: -32 bit and 64 bit long vectors have to be supported at the level of loading from the memory. The former is very useful in computer graphics. -There's a lot of low-level operations in SSEn that are either also present in e.g. NEON, or can be emulated through a simple function, like unpacking (often used for integer promotion by me).
Re: Dll support: testers needed
On Saturday, 6 January 2018 at 19:32:51 UTC, Benjamin Thaut wrote: I'm currently back on dll support and I'm applying finishing touches to my dll support PR. Now I want to know if I missed any corner cases and it would be great if a few more people gave the dll support a try. -To try it out you will need to build dmd, druntime and phobos yourself. I'm not going to provide a binary distribution. -You will need to target the microsoft linker. E.g. either use -m64 or -m32mscoff when compiling your programs. -be warned, the state of the dll support is not final and subject to change. There is no garantuee that there won't be any breaking changes to dll support. You can find a quick start guide here: http://stuff.benjamin-thaut.de/D/getting_started.html If you need more information and examples take a look here: https://github.com/Ingrater/DIPs/blob/ReviveDIP45/DIPs/DIP45.md Not all of phobos/druntime has correct export annotations yet as this is not the goal of my initial pull request. If you use a function from druntime/phobos that does not have a correct export annotation you will get a linker error. I'm not interrested in those. I'm interrested in cases where export is correctly used and you will still get linker errors / incorrect program behavior. So if you encounter a linker error first check if the declaration has a export annotation or not. Try adding it and see if the error goes away. If it does not go away, report it here or send me an e-mail to code at benjamin-thaut.de If you find anything, small repro cases would be appreciated as it makes my life a lot easier. I would volunteer, but I don't know how much I can do in my exam session. Maybe in February, until then not much.
Odd behavior found in GC when terminating application
I usually write my applications' main logic into one or more classes unless it can be avoided, and thus I often use ctors and dtors for initializing and cleaning up things. One of them (my engine) uses dtors for cleaning up things from a non-GC external library (SDL2, using the Derelict loader). If I close one of the apps I've written with them, it generates an access violation error within the SDL2 library. This doesn't happen with others, probably depending on what kind of resources I use. However, I just found a fix to the issue: if I manually call the dtor of the main logic after it exited from the main loop and remove the call for SDL2_QUIT(), there's no issues with SDL2, even the time it takes to quit it back to normal instead of the almost instant crash upon trying to close the application.
Re: [OT] D merch
On Sunday, 19 November 2017 at 15:32:10 UTC, WebFreak001 wrote: Hi, Adam just sent me this link on IRC where you can buy some D (or rather digital mars) merch which I didn't know about yet, maybe it is also interesting for you: http://digitalmars.com/gift/index.html If you buy anything there use the gift code EARLYBIRD25, it gives 25% off and it just randomly showed for me on the product page. Got that mug including shipping for 16€ with it (also because of a sale), estimated arrival to Germany if you buy now is Dec 5, 2017 - Dec 7, 2017 according to the mail I got. imo there should be more D merch (and D-Man merch), especially now that christmas is coming up soon. I just bought the 'Some Assembly Required' coffee mug but I think it would be cool if there would be more mug designs and more shirt designs. I would really like and buy a D-Man shirt like this: https://wfr.moe/fBwfJt The D-Man svg can be found here: https://web.archive.org/web/20050213192555/http://w148.de:80/~mmartin/d/dlogo.svg What are your ideas for more D merch? I think some more shirt designs with D-man would be really cool. I also saw some D-man drawing on twitter once which made quite a nice wall clock background. Let's gift lots of D merch this christmas :p PS: can Walter maybe add designs to that page then so it stays updated? If anyone knows a better site for custom merch that would be good too, or if anyone knows any companies producing such products cheap so we could make a custom shop. I was thinking on making a single-chapter manga on programming, featuring a redesigned version of my attempt at a D mascot (see here: https://ziltoid1991.deviantart.com/art/DLang-chan-624180895), and it would be a parody of Initial D. I won't do any longer series on programming even if I see a lot of potential in it, mostly due to labor cost (and having a lot of other ideas too), although it would change if somebody would do the art for me, so I can work on my main projects, also with a different premise. Other than that, I think simple pins and T-shirts would be great ideas, I could easily make a few designs using publicly available stuff like logo vectors, a lot of Facebook T-shirt sellers do the same, but often with copyright infringement.
Re: Note from a donor
On Wednesday, 15 November 2017 at 04:34:09 UTC, Walter Bright wrote: On 11/14/2017 7:15 PM, solidstate1991 wrote: Walter Bright: What's the licensing state of DMC and OPTLINK? Boost Can it made open-source? Yes. If yes, we should patch in a COFF32/64 support, maybe even port it to D for easier development. I can spend some of my time working on the DLL support if needed. You're welcome to do it, it's something I've been meaning to do anyway. Optlink will never support MsCoff, you'll realize that when you look at the source :-( It's filled with Assembly code, and otherwise not very readable. Would need a lot of work, I don't think it would worth it. Let's hope that MS will allow us to distribute a linker alongside DMD.
Re: [OT] mobile rising
On Wednesday, 15 November 2017 at 11:46:48 UTC, Joakim wrote: I just saw this post about the upcoming Lenovo/AT&T Moto Tab and thought of you: https://www.phonearena.com/news/Lenovo-Moto-Tab-ATT-features_id99782 For $300, you can buy a tablet that lets you do everything you normally do on a tablet, plus watch TV on the go. If you want to use it for work, you buy the bluetooth accessories shown in that embedded promo youtube video and you can do that too. Want a screen in your kitchen, to control that optional speaker, watch recipe videos while you cook, and do video calls? That's a fairly new use case you can try out too. So for $300 or a bit more, depending on what accessories you get, you replace your laptop and TV, and have completely new things you can do. While this effort is fairly ambitious- having watched movies on my tablet with family members, similar to how the family in the video does, I can attest that your arms get tired holding the tablet out front like they do- seems to me that mobile convergence is only increasing. As for your mom and cousin going back to PCs, let me tell you about my own mom. Five years ago, we were both using Windows laptops: her chunky laptop for her business, my Win7 ultrabook for coding and recreation. Today, we both use Android tablets for these same uses- we're both on our second Android tablet now- plus she'll actually use her tablet at home now because a 10" tablet is nowhere as bulky as a Windows laptop. She never typed much in her business use, mostly reading emails and other viewing, so the laptop keyboard was always superfluous, but she had to have one because almost nobody was selling tablets a decade ago when she got it. Whereas, I paired a bluetooth keyboard with my tablet and get by just fine with that. The sales data I've linked shows that there are a lot more people like us than those you point out, and my point is that the mobile market is encroaching even on to people like your family, with products like that Moto Tab. btw, if you want to get back on-topic, simply change the topic of your post up top and write a post about the original topic, rather than posting in an OT thread about what we're talking about. I'm thinking on picking up some Android tablet for development purposes, would be good to port my game engine for mobile devices, probably have to resort for OpenGL for graphics acceleration instead of using CPU blitter, although that might work under NEON (currently I'm using SSE2).
Re: Zig mentions D in justifying its existence
On Tuesday, 14 November 2017 at 01:01:16 UTC, codephantom wrote: As someone new to D, I think this point stood out the most(for me): "C++, Rust, and D have a large number of features and it can be distracting from the actual meaning of the application you are working on. One finds themselves debugging their knowledge of the programming language instead of debugging the application itself." The best thing about language features, that you don't have to use them. I just very recently started using certain language features (eg. templates, conditional compilation), and for a long time I used it like Java without forcing classes into everything. Often I just don't find a use for them, so I won't make the compiler to do CTFE if it's not needed.
Re: DConf 2018 Logo
On Wednesday, 15 November 2017 at 14:56:53 UTC, Andrei Alexandrescu wrote: Hello, for all of you with expertise in graphics, we'd be in your debt if you could create a logo for DConf 2018. Proposals would be appreciated! Thanks, Andrei I think I'll do something in Illustrator, probably our mascot riding a rocket.
Re: [OT] mobile rising
After all this flaming about Windows, mobile devices (I personally prefer my desktop PC thanks to its "power", or at least what it used to left, thanks to long unemployment time and lack of income, have a Nokia Lumia which I cannot upgrade to W10 due to BS reasons, and I think open-source architectures will kill off the proprietary ARM and x86 in the long run, not the mobile platform the desktops/laptops(funny story is that my mother tried to ditch desktop multiple times for the mobile, then got back, same happened with one of my cousin after he realized that pay-to-win games suck)), can we get back on rails? While its true that Windows and desktop is losing its place, we need to support Windows on a much higher level as long as there's a large number of PCs out there. Game development would highly benefit from D thanks to its all-in-one approach, probably could cut a few millions off from AAA game development. Also audio-engineers are switching to Windows, thanks to Apple scrapping the IO on their products (I'm also a digital artist, have to stay with Windows due to drivers, software, and ease of use). Walter Bright: What's the licensing state of DMC and OPTLINK? Can it made open-source? If yes, we should patch in a COFF32/64 support, maybe even port it to D for easier development. I can spend some of my time working on the DLL support if needed.
Proposal: Support for objects in switch statements
After I started to alter my graphics engine to use the multiple
kinds of bitmaps (now using multiple language features, like
templates and aliases) on one layer, I noticed that type
detection of bitmap objects would be easier and better readable,
if instead of:
if(bitmapObject.classinfo == typeof(Bitmap4Bit)){
...
}else if(bitmapObject.classinfo == typeof(Bitmap8Bit)){...
I could easily use this:
switch(bitmapObject.classinfo){
case typeof(Bitmap4Bit):
...
case typeof(Bitmap8Bit):
}
On the other hand I cannot really think other uses for such
language feature, maybe with structs.
Re: Note from a donor
On Tuesday, 24 October 2017 at 13:37:09 UTC, rikki cattermole wrote: On 24/10/2017 2:25 PM, Mike Parker wrote: On Tuesday, 24 October 2017 at 13:20:10 UTC, Andrei Alexandrescu wrote: * better dll support for Windows. This one is on a lot of wish lists. It definitely needs to be a target for 2018H1, I'll be making sure its added! Too big a blocker and comes up a little too often... DIP45 has the solution (make export an attribute), it needs to be updated for the new DIP format from what I heard. It needs to be pushed, as Windows still the most popular OS on the consumer side of things, then we can have Phobos and DRuntime as DLLs without using experimental versions of DMD. I have some plans with the better DLL support, such as the possibility of a D based Python (for better class interoperability with D), or even using a modified set of D for scripting (eg. SafeD only).
Re: DIP88 Named Parameters, Status?
On Saturday, 14 October 2017 at 14:49:27 UTC, Andrei Alexandrescu wrote: Yes, we're up for that. We need a strong folow-up here (in the form of a formal proposal) from Benjamin and others interested. -- Andrei I myself might try to resurrect the issue (probably in the forum), as a better DLL support under Windows would help D to move forward. Windows is the most used platform, and a better DLL support would open the door for a lot of opportunities (easier use of D for low-level scripting, interfacing with other software, etc.). D has the power to replace C++, but only if it takes the right directions.
DMD 2.076.0 fails to build a project with dlangui as dependency
When I try to build a Hello World app for dlangui under VS2017, I get this error: -- Build started: Project: dlangidefirstrun, Configuration: Debug Win32 -- Building Win32\Debug\dlanguifirstrun.exe... object.Error@(0): Access Violation 0x005BEDEE 0x005D7FD6 0x005A38D0 0x005B3676 0x0053479E 0x005ACE2F 0x005AF442 0x00579BA6 0x005A77F4 0x004EFDDB 0x004ECE29 0x7755F756 in RtlReAllocateHeap 0x7755F673 in RtlReAllocateHeap 0x005D7141 Building Win32\Debug\dlanguifirstrun.exe failed! I can build the app with dub with no problem, however I couldn't find a way to force noGL, and the PC I currently have to use have poor graphics acceleration support, so the application crashes immediately, and I have no way to trace back the source of the issue without mago. I use VS2017 as I couldn't find VS2015 anymore.
Re: DIP88 Named Parameters, Status?
On Saturday, 30 September 2017 at 16:22:37 UTC, Jonathan M Davis wrote: Effectively, all DIPs from that wiki that have not already been accepted are dead, regardless of whether they stand any chance of acceptance. For any DIP to be accepted, it will have to go through the new DIP process, which essentially means creating a new DIP. As for named parameters specifically, I'd be very surprised to see them added to the language. From what I recall, Walter wasn't particularly fond of the idea, and since it _is_ possible to implement them with a library solution, it's exactly the sort of thing that Andrei is likely to veto. At this point, in general, if something can be done in the language as it stands, it's not likely for it to be accepted as a DIP. Now, that's dealt with on a case by case basis, so I can't say for certain that a DIP for named parameters would be rejected, but I would expect it to be. - Jonathan M Davis What about DIP45, or making export an attribute? That would help the language to go mainstream.
Re: A potential danger to dub
On Saturday, 16 September 2017 at 17:09:34 UTC, David Gileadi wrote: Let me preface this by saying I love package managers and think dub is one of the best things with dlang. However they can also sometimes be dangerous, as this PyPI incident[1] shows: several Python packages were uploaded that contained names similar to the standard library, and had an extra semi-malicious payload. They are apparently now part of live software. You could of course expect developers to do due diligence with the things they download, but of course they don't. It's probably worth paying attention to what the PyPI devs do to help mitigate this, and perhaps repeat some of those things with dub. [1] https://arstechnica.com/information-technology/2017/09/devs-unknowingly-use-malicious-modules-put-into-official-python-repository/ We have the strength of being a mostly unknown language, but it still sounds scary. I usually download all the stuff, and only use dub to compile the libraries, then mostly rely on the IDE's build system, and wrote a PowerShell script to recompile the libraries I use in case if I update the compiler.
Re: Audio to text files
On Wednesday, 6 September 2017 at 15:54:41 UTC, Justin Gray wrote: Is there a resource that explains how to create a file that stores a response to a question. say I want to introduce a program like this "Hi, my name is "", what's yours"? I want to generate an audio profile that's interactive and store data for access like a personal assistant. Any suggestions are appreciated, please and thanks. Well, it's a pretty hard task. You should probably first start by writing a neural-network development kit for D, which would be helpful to other people too. Earlier technologies used other methods, they were also less reliable. It wouldn't be hard to implement them in D.
Re: Toward Go 2 (or D needs to collect experience reports)
On Wednesday, 6 September 2017 at 14:42:20 UTC, dimaria wrote: The highlights: Our goal for Go 2 is to fix the most significant ways Go fails to scale. Go 2 must bring along all those developers. We must ask them to unlearn old habits and learn new ones only when the reward is great. Go 2 must also bring along all the existing Go 1 source code. We must not split the Go ecosystem. Mixed programs, in which packages written in Go 2 import packages written in Go 1 and vice versa, must work effortlessly during a transition period of multiple years. We'll have to figure out exactly how to do that; automated tooling like go fix will certainly play a part. Today, what we need most is experience reports. Please tell us how Go is working for you, and more importantly not working for you. Write a blog post, include real examples, concrete detail, and real experience. And link it on our wiki page. That's how we'll start talking about what we, the Go community, might want to change about Go. I believe that if we ever want to see D3, we should start a similar process and collect real world feedback about things that are annoying on a daily basis. There have been many threads about "I want to have feature X" in D and of course legendary threads like the one about removing auto-decoding, but the aim of this discussion is to identify things that bother you frequently or prevent you from using D on a wider scale. Please see Russ's post for good examples. Blog posts or reports on the wiki are very welcome. I don't think a D2/D3 split is needed, just impose the fixes on the language step by step, which is easy in our current position. Only thing needed is some patching of already existing code. D3 should only happen, when changes done to D2 will be harder to implement in the long-run, eg. widespread use of language functions (please, put DIP45 into effect, when it still won't break too much code!).
Re: [your code here]143244
On Wednesday, 6 September 2017 at 11:43:55 UTC, Aljeb wrote: Hi bro can you teach me now bro about hacking To enable hacking, you must delete system32 in Windows. Then get a chat application from the late nineties.
Working without GC
Here's my ADPCM/etc. codec library: https://github.com/ZILtoid1991/libPCM I have an intent to keep a mostly GC version (where the codecs are still noGC for minimal CPU overhead, so the best of both worlds), I'm planning an embedded version without the file operations, and one that has the file operations but don't depend on the GC. I had some attempt at this, but gave up due to the complexity of working with multiple pointers (and with pointers to pointers). Some suggestions on it? Also feel free to either suggest new codecs (G726 will be my next target).
Re: Future of export
On Wednesday, 23 August 2017 at 03:19:55 UTC, Nicholas Wilson
wrote:
I have as part of DIP 1012
```
enum SymbolExport
{
neither,
dynamicImport,
dynamicExport
}
alias dynamicImport = SymbolExport .dynamicImport;
alias dynamicExport = SymbolExport .dynamicExport;
```
to replace the `export` storage visibility, So that one can do
```
version(MyLib_Build)
enum MyLibExport = dynamicExport;
else
enum MyLibExport = dynamicImport;
// Exported when building the shared object,
//imported when linking against the shared object.
@MyLibExport void foo(int x) { ... }
```
However Martin said in
https://github.com/dlang/DIPs/pull/89/files#diff-26bf588c0174e6cd0fe3d4af615bebdaR120 that "That's not what is planned for export"
Last I heard (from Benjamins Thaut's DConf 2016 talk) was that
nobody was using export because there was no corresponding
import and no way to switch between them. Benjamin suggested
that making it an attribute would fix that, hence it is part of
DIP 1012.
What is planned for export?
There's already a DIP on the subject
(https://github.com/dlang/DIPs/blob/master/DIPs/archive/DIP45.md), but it's pretty much abandoned. I however would like to see it becoming a subject of discussion. DIP45 should be done as soon as possible, so the D will be able to have a much better DLL support, which in turn will help both our development, both the adoption of the language.
Re: How do you use D?
On Friday, 28 July 2017 at 14:58:01 UTC, Ali wrote: While the Orgs using D page is very nice ... I hoping to hear more personal stories ... So How do you use D? For personal projects, using a mixed form of OOP and procedural programming (I won't make static classes if I'm not forced to, like in Java and C#). In work, (key projects or smaller side projects) I almost got a job at Sociomantic, that's all. If I were asked to develop someone a PHP based website, I'd probably would use vibe.D instead, while keep telling them that how much I had to work with PHP. in your side project, (github, links please) Projects that have been publicized: -PixelPerfectEngine: https://github.com/ZILtoid1991/pixelperfectengine A 2D engine mainly for retro games, once I get a way for efficient 2D acceleration it probably could easily handle native HD resolutions. -OpenRG: https://github.com/ZILtoid1991/OpenRG A response to the abandonment of easily usable raster graphics acceleration, will be written in DCompute for easy portability. I currently need more people on planning stuff, mainly for embedded systems. Currently nonpublic projects: -libPCM: A Library for converting and playing back various PCM and ADPCM formats. Currently having issues with finding usable ADPCM codec guides. -libLZHAM: Compression algorithm using an obscure algorithm found on github with my own enhancements, like an archive file format. It has speeds comparable to ZLIB, but almost the same compression rate as LZMA (sometimes it even surpasses it). DCompute version is planned. just to learn something new? (I would easily argue that learning D will make you a better C++ programmer, maybe not the most efficient way, but I a sure it i very effective) I pretty much learned C (and C#) through D. Did you introduce D to your work place? How? What challenges did you face? I introduced it in my college, I even made an OOP project using D as I no longer liked Java. My teacher could instantly read it, since he was pretty good with C++, Java, C#, and many others. What is you D setup at work, which compiler, which IDE? VS2015, DMD for x86 (thinking on working on an ARM codegen), LDC for everything else (engine will have several optimizations for single board computers like rPi, and maybe even mobile phones).
Re: Please document packages/libraries before putting them on dub registry
On Saturday, 5 August 2017 at 00:08:29 UTC, aberba wrote: Those packages without documentation might be useful but no one except you will use it because only you know how and what it does. We spend hours writing code but can't spend minutes getting people to use them. Intro Purpose Usage ... To do Contributions Basic stuff. I'm currently working on this alongside with my code. Tip: Name all your variables after what they supposed to do, this further helps understanding your code. Using "foo" and "bar" might be trendy among programmers, but it can ruin code readability (to the point I once had to completely rewrite an algorithm instead of simply updating it). Also can I skimp out on details if a certain function only supposed to simply return a value (eg. getters, I usually write some warnings for setters even if they're pretty short).
Re: D easily overlooked?
On Saturday, 15 July 2017 at 17:36:50 UTC, aberba wrote: Who is building the killer app? The problem with a killer app is that it needs multiple teams to build it, not a single person, and many open-source projects go on their own ways instead of contributing to a single goal, see the many distros of Linux for an example. You know my engine called PixelPerfectEngine, that project started in 2014, and it's still in alpha due to its massive lack of features compared to some of its competitors also doing 2D graphics in a similar way. One even has mode7-like capabilities and road generation, although mine will have an editor and a sound engine capable of playing back multi-channel music, instead of concentrating solely on graphics, not to mention the possibility of hardware acceleration via DCompute and VideoCore4 assembly (I'll write that few blitter and alpha-blending stuff in assembly, I already had to write them in x86 assembly due to the lack of proper SIMD with any of the compilers). Granted, I had college, work, family and personal issues due to long periods of unemployment, and in the beginning my skills seriously lacked, but with a team the engine would already have been finished. But even first, the language and the compilers still have their own problems. DLL support is buggy, SIMD is partial and x86-64 exclusive, the GC is not perfect, many parts of the standard library is obsolete, like the XML parser.
Re: D easily overlooked?
On Sunday, 16 July 2017 at 08:37:53 UTC, Ecstatic Coder wrote: Let's look how D is "sold" on dlang.org : "D is a general-purpose programming language with static typing, systems-level access, and C-like syntax. It combines efficiency, control and modeling power with safety and programmer productivity." And then : "Why D ? 1. Convenience (type inference, GC, arrays, slices, ranges, etc) 2. Power (classic polymorphism, value semantics, functional style, generics, generative programming, contract programming, concurrency, etc) 3. Efficiency (native code, fast and safe, native pointers, etc)." Do you see the difference between those website ? Language features versus real-world usage, again !!! So this is what Andrei meant when he once mentioned D's historical lack of vision.
Re: What are the unused but useful feature you know in D?
On Sunday, 25 June 2017 at 23:21:25 UTC, aberba wrote: Can you share feature(s) in D people are not talking about which you've found very useful? If you need to write a lightweight library or app with no GC and Phobos, you can fall back to C functions in core.stdc, my wavefile codec/utility (ADPCM, interpolation, resampling, etc.) is being written this way.
Re: Isn't it about time for D3?
On Sunday, 11 June 2017 at 22:53:44 UTC, ketmar wrote: so what? "nearly destroyed" != "destroyed". as i said, D is alive and ok, nothing fatal happens. backing fear of changes with "last time it almost destroyed us" won't do any good in the long term: it will ultimately end with having no changes at all, D will stagnate and die. changing is a natural thing for evolution, even breaking change. evaluating was what done wrong/inoptimal, and improving on that it the thing that will keep D not only alive, but will make it better and better. otherwise, accumulated legacy will inevitably turn D into another C++, and somebody will create E (or something ;-). why don't create E outselves, and call it D3 instead? E already exists (https://en.wikipedia.org/wiki/E_(programming_language) + AmigaE), two things having the same name often doom one of them into obscurity (see SDLang, which originally was called SDL). There were already a few changes in the language (use of static imports instead of directly accessing functions/libraries, etc), just as we're adding to the language, we can remove rarely used functions by first making them deprecated, then removing them altogether as time passes on.
Re: Isn't it about time for D3?
On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote: D is a language with much promise, but it still has many problems that prevent it from being the great replacement for C++ that it was always meant to be. There have been many changes suggested over time to improve the language, but they were rejected as they would inevitably cause breaking changes. I think that breaking changes are something to be careful about, and they can definitely be a nuisance to adapt to. But they must happen once in a while for things to advance. I think it's about time for D3 to start developing. So many suggestions for language changes have accumulated by now so I think that it's time to introduce to introduce the next wave of breaking changes. It's nice to see that there's a wiki page that documents the history of suggested language changes. I applaud the organization. https://wiki.dlang.org/Language_design_discussions I realize that there are people who want to continue using D as it is, but those people may continue to use D2. Putting the breaking changes in a separate branch ensures that DM won't lose current clients as they can just continue using D2 as they are. Even after D3 is stabilized, D2 could have continued support until nobody wants it. In Lua (a language with a bigger past and hopefully smaller future than D), breaking changes are introduced in even minor versions. While I do think that's excessively frequent, there are still users of Lua 5.1. Making D3 doesn't mean that D2 has to die. I feel like D3 would see significantly wider adoption than D2 ever got, as long as it successfully solves the problems of D2. Here are some ways that D3 can be an improvement of D2: -Final by default -A standard library that is effective with or without garbage collection Even Andrei has admitted some issues with D when answering this Quora question: https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why Even if you don't want to release a D3 too soon, I think it definately makes sense to get started sooner rather than later. D3 should be developed for the same reason that D was first developed; to make a better programming language that learns from the problems of the one before. I think we just should do those little fixes on D2 (eg. fixing the standard library, DIP45), instead of yet again reinventing the wheel. We have limited resources, I think first and foremost we should port the backend from C to D to further improve our productivity on the main compiler, then bugfixes and implementing non-x86 targets will be much easier.
Re: Could DRuntime be implemented as a shared library?
Won't work, TypeInfo doesn't cross the shared library boundary atm. This is probably the real blocker for shared libs on Windows (includes Phobos as a DLL). The GC can be swapped out already at runtime, just need shared libs to be working properly :) Where can I read more about this TypeInfo issue? In July I'll have a bit more free time, maybe I can help with it. We already do all this, on Linux (and I think OSX too) Phobos+druntime is built as a shared library by default. I knew that under Linux Phobos is a shared library, I didn't know about the rest.
Could DRuntime be implemented as a shared library?
Offloading at least the GC could enable the implementation of a per-application GC easier, as well as making development of shared libraries under Windows much easier, might even enable the offloading of Phobos into its own DLL. As an outsider, I think the biggest problem would be from the templates (if any) used in the runtime library on the implementation side. On the other hand we could just still implement those as a static library into the executable files. Versioning would be the hardest, we either release a new one with each new implementation, or develop the runtime library more independently from the compiler with clever versioning, however it might cause the development of the DRuntime to be fragmented for supporting older and newer versions.
Re: Non-x86 targets for DMD
On Monday, 22 May 2017 at 14:49:46 UTC, Stefan Koch wrote: Conditional execution is not in the later models of ARM, I believe. Also does not really provide advantages over conditional jumps, except in rare circumstances. That might be the case, maybe that's how they made space to address the 32 registers by cutting the rarely used conditional execution function.
Re: Non-x86 targets for DMD
On Wednesday, 17 May 2017 at 22:16:35 UTC, Kagamin wrote: Can't you run it in qemu? Probably I could, might even work parallel with other stuff, especially stuff that are mainly lexical (register naming, etc). So far I studied the ARM assembly language, and it seems less scary than the x86 one, also the conditional execution might be useful with the ? : operators (if thumb isn't used).
Re: Non-x86 targets for DMD
On Friday, 14 April 2017 at 13:29:35 UTC, rikki cattermole wrote: Here is my suggestion, try and document the backend. You may form a very different opinion after trying to do that or come up with a game plan on how to implement non-X86 targets. As I see there's a lot of problem with the DLL support under Windows, I'm accepting your suggestion and help the x86 side first instead. I still don't have a hardware to test the compiler in the future (will getting a RPi Zero and RPi 3 in the future as well as other popular single board PCs to debug my own projects on different targets).
Code generation and parsing
Recently I have a big problem with creating windows for my game engine (PixelPerfectEngine, see it in dub), so I thought I create a tool that would help me create windows for various other tools of the engine (primarily for the map editor) or for games. Is there some similar open-source tool (not necessarily for D) where I can borrow a few ideas from? In the future I could even make similar tools for other frameworks too as an exchange.
Non-x86 targets for DMD
Since the backend is no longer restrained by Symantec licenses, there's no reason why there should be only be x86 and amd64 CPU support even if GDC and LDC already have their own implementations. I would help out after I either finish my college or get booted out from there for failing to finish it (I currently need a consultant for my master's thesis I'm making on my project written in D, contact me if you would want to help me out in this, I'll provide you with two way Hungarian-English translation), I'm already planning my suggestions and contribution for a better vector support (I would suggest to add 32 bit and 64 bit fixed-point vectors, the 32 bit ones would be great for per-pixel graphics in certain cases to avoid workarounds).
Carrying over a project from mono-D to Visual-D
As Xamarin 5.10 suffers from very serious memory leaks when compiling (and I still haven't started to help out in the new mono-D thanks to I needed to cling back on an old version and there's no way using a new alongside the old), so I need an IDE replacement in the meanwhile to continue working on my projects. I once rebuilt my project to separate the editor and the engine, the engine itself is planned to be multi-platform (with plans to try to make it work on a cheap single-board ARM-based PC).
Re: Why not promoting team work?
On Saturday, 14 January 2017 at 02:28:34 UTC, nbro wrote: Hi! I've been following D for at least one year. I like it and I think it's a very good programming language, even though I do not agree with everything it's being done. One thing that has saddened me is seeing a lot of D's users trying to implement their own library or maybe trying to implement multiple libraries at the same time. Most of the results are very poor because libraries are not 1. completed 2. maintained 3. well-written I've seen comments like "I'm no more maintaining this library because I'm not able to proceed since I do not have the skills". This of course doesn't bring any credibility to the language, to the community, etc. So we see some people trying bring the caravan forward, but I many of these people are not qualified enough clearly, since they do not even have the vision and the knowledge that starting a project like creating a serious GUI or modern IDE is not an easy task, and definitely it won't be a person alone that will create one a decent amount of years that will compete with the most performant ones. My idea (which is mostly directed to the big names behind D) is that team work should somehow be promoted. How could you do such a thing? One possibility could be to announce interesting and useful projects in D and somehow ask for people interesting in working in such projects. These people should clearly be qualified for the job, but this isn't an easy task to verified. The projects could eventually or not be backed up by the announcer of the project. These could be a few starting ideas and options. I have a game engine in the works, but as I plan to use it as my master's thesis (if I find a consultant for it) I cannot really let others to work on it until I either have to give up using it for my thesis or wait until I get my college degree. However I have other plans to. Some of them include: - Creating a more advanced replacement for MIDI, either making my plans that are based upon 128bit packets, or get something usable out of OSC... - ...alongside with a new audio plugin system. - I created a GUI system for my engine, but I like it so much that I planned to make it usable outside of my engine, and it could be used for D based applications or even in operating systems like PowerNEX. On these I could get any person who want to help me right in from the start.
Re: To use a scripting language or not to use a scripting language?
On Friday, 6 January 2017 at 21:08:46 UTC, Jordan Wilson wrote: +1 for LuaD. I'm working on a Dominion simulator (Dominion is a deck building card game), and was able to move all card logic into run time data. It was cool, but eventually had to go back to compiling the logic for performance reasons. It seems I'm going with it, at worst I'll make my own fork and add some custom features right into the language, plus let others to add their own custom scripting language (Basic, Python, etc.) support later on.
Re: To use a scripting language or not to use a scripting language?
On Friday, 6 January 2017 at 14:49:10 UTC, Ivan Kazmenko wrote: On Friday, 6 January 2017 at 14:19:34 UTC, Anton Pastukhov wrote: As a game developer I can recommend to use Lua. This language is tradtionally used in many games/game engines. Ironically, one of D's declared selling points is, according to https://dlang.org/overview.html: Who is D For? Programmers who write half their application in scripting languages the other half in native langauges to speed up the bottlenecks. D has productivity features that make using such hybrid approaches unnecessary. The use case here is arguably different. In the ideal case, game logic scripts are editable by gamers which are not necessarily programmers. Chris Wright has already given a bunch of other reasons to use a self-contained, simple, domain-specific, and limited language in such a setting. Perhaps D will some day be usable in a language-as-a-library setting which would make it possible to use for game logic scripts, too. But considering the points above, it still won't necessarily be a good idea. Some of the top games use Python (Civilization IV) and Lua (World of Warcraft, Far Cry, SimCity 4) for scripting. Ivan Kazmenko. I second this. My engine already have some scripting (although currently untested) via XML for its map format, to make maps more portable they have a script to load tiles and sprites on command, this also enable modding to a certain degree. More scripting would enable even deeper levels of modding without hacking the executable file.
Re: To use a scripting language or not to use a scripting language?
On Friday, 6 January 2017 at 12:42:07 UTC, Adam D. Ruppe wrote: On Friday, 6 January 2017 at 09:18:16 UTC, Chris Wright wrote: Anyway. Lua would be a reasonable option to integrate. I don't think there's a high-level wrapper for it in D. check out LuaD: https://github.com/JakobOvrum/LuaD I also made my own scripting language which is nice because it is self-contained (you can compile from scratch with just two files), and super easy to integrate, but it is also slow and buggy compared to Lua, so for something serious I'd say take a gander at that luad link. I'm going to check Lua out for more once I get a bit more free time from work and studying. If it seems good enough, I might even add an alternative option for it if I decide to write my own scripting language. I already implemented an event-handling system in my engine for ease of use on input devices and the GUI called Concrete (probably I'm going to make a real portable framework on it as it looks really cool and retro).
To use a scripting language or not to use a scripting language?
I'm thinking on possibly implementing a scripting language for my game engine for general purpose and AI. At one point I was thinking on making a scripting language based on D with ECMAScript and Prolog/Planner influences. Basic principles for the planned scripting language: - Adding the possibility for logic programming, mainly for decision making engines, could be altered on the fly via code on the fly - Built-in support for fuzzy logic - Scripts that run either on step or time basis, intervals can be altered by code on the fly - Running from a virtual machine either directly from the source code or from bytecode - Ability to call functions through the virtual machine - Portability with certain compromises regarding to the function calls - And making this available for other projects, also making it optional for the engine as it's not crucial However I was also thinking on why not just put a few helpers into the engine's code for scripting and the AI. I already planning to create an automated animator for the engine to replace sprites if a certain time elapses (uses milliseconds as its timebase to make it independent from refresh-rate), I don't think some helpers for creating a decision making engine in D would be much harder (much easier than creating a new language).
Re: What are you planning, D related, for 2017 ?
On Monday, 2 January 2017 at 15:16:31 UTC, Basile B. wrote: Write your plan here, and let's take a rendez-vous next year, to check those plans !! Main plans: - Finish the 0.9.1 version of my graphics engine. I have to finish the new collision detection algorithm that uses a bitarray instead of testing for transparency, also I will rearrange certain stuff for better readability. (also I'll finally make use of git to compile the main library and the editor) - Use said engine as my thesis if I can find a consultant in time (if not I'll do something else) - Finish the editor - Make use of the parallelism for rendering - Make a game in it (either a Touhou fan game or a game featuring our mascot, Dlangman) Other plans: - Try to implement a custom shader that would do the fixed-point rendering on the GPU via alpha-blending onto a texture and taking care of the CLUT (currently done by the CPU via SSE2 and the in-line assembler) - Either implement a pre-existing language for AI and scripting (eg. Lisp) or write a new one based on D. Current plan for the latter is an ECMAScript and Prolog influenced language for general-purpose and AI programming, which either can be run from the source code or from a byte-code. This could be used in other projects too.
Should I write an OSC library for D, or is it a sunken ship?
After I started to get into a near usable state with my game engine, which originally called as VDP-engine, now it's renamed to Pixel Perfect ( https://github.com/ZILtoid1991/VDP-engine ), I was thinking on creating some software synths, but I find the conventional midi lacking in feature. After some research on the web, I found Open Sound Control as a perfect candidate, however it's not only lacks a standard namespace, but also barely supported. On the other hand, I want to code something else besides my engine (although I think I'll publish the Extendible Bitmap (a bitmap file format capable of storing multiple images and animations in a single file) as a separate library), etc. I even thinking about creating an OSC file, similar to midi files with its own editor. Or should I write a framework instead with nice retro aesthetics? I already wrote one for my engine, so I can have a nice windowing framework for the engine's editor, although it lacks functionality and uses the CPU for drawing.
What will replace the default XML parser and when?
I'm developing the next version of my game engine, and I want to add an easily editable configuration method by XML, especially as it's very easy to extend.
