Re: Announcing audio-formats v1.0.0
Guillaume Piolat wrote: Any input concerning stb_vorbis vs Tremor? Tremor is twice the code size and I'm not sure the one to be favoured. tbh, i didn't really tested stb much (if at all). it *should* work, but... my audio player was based on tremor, so it is better tested. maybe just make `version`, and let the user decide? ;-)
Re: Announcing audio-formats v1.0.0
Guillaume Piolat wrote: On Wednesday, 18 March 2020 at 18:49:23 UTC, ketmar wrote: glad you found it useful! but why only that? there is GPL Opus decoder too, and two decoders for Ogg/Vorbis: stb and complete port of the official Xyph tremor library. also, you can find a resampler there, taken from Speex. are you planning to use those too in the future? It's a triple "yes". I haven't yet found the time to do it but figured it could be useful already :) Hope you are well ketmar. yeah. and thank you for your work! that code was simply rotting there, but now people may find some use for it. i am very bad at making my code useful for others, so i really appreciate your efforts! thanks again!
Re: Announcing audio-formats v1.0.0
Guillaume Piolat wrote: On Wednesday, 18 March 2020 at 18:41:11 UTC, Guillaume Piolat wrote: audio-formats is a new pure D #DUB package that allows to decode and encode audio files. Also: it's just a custom repackaging of the huge work of Ketmar. https://repo.or.cz/iv.d.git glad you found it useful! but why only that? there is GPL Opus decoder too, and two decoders for Ogg/Vorbis: stb and complete port of the official Xyph tremor library. also, you can find a resampler there, taken from Speex. are you planning to use those too in the future?
Re: I was able to write some D last week!
Adam D. Ruppe wrote: I am bumping the arsd repo dub's version number to 4.0.0. (this is super super arbitrary for me though, I very rarely ACTUALLY break backward compatibility, in fact I try to be both backward and forward compatible with myself and with dmd versions, just meh) yay, so your cgi.d and template modules are ready for public now! great.
Re: now it's possible! printing floating point numbers at compile-time
H. S. Teoh wrote: actually, there is a 3rd issue, which is often overlooked: conversion from string to float. to get a perfect roundtrip, this one should be done right too. Doesn't hex output format (e.g. std.format's %a and %A) already solve this? It basically outputs the exact bits in hex. No room for error there. it does. but then you can simply go with writing binaries as-is -- they are not really less readable than hex floats. ;-) but we want decimals! ;-)
Re: now it's possible! printing floating point numbers at compile-time
Basile B. wrote: On Sunday, 30 December 2018 at 12:19:19 UTC, ketmar wrote: too bad that i didn't knew about Ryu back than. It's very recent, announce on proggit is < 1 year. It would be nice to have one to format in phobos. RYU or Grisu3 doesn't matter much as long as the two issues that are - CTFE formatting of floats - formatting is identical on all platforms actually, there is a 3rd issue, which is often overlooked: conversion from string to float. to get a perfect roundtrip, this one should be done right too. is solved. There's also the "real" problem. I'm pretty sure that 32 and 64 bits floats are always handled. Someteimes 128 bits ones but not sure for 80 bits... 80 bits can (usually) be extended to 128. you'll get some extra meaningless digits, of course, but it is better than nothing, i think. actually, Ryu has all the math to derive 80-bit implementation. it will require 128-bit integers, though. (less than 128, but there is no sense in using smaller ints anyway).
Re: now it's possible! printing floating point numbers at compile-time
i think that porting Ryu will get us the fastest one (and with smaller/easier code). and without pathological cases of grisu too. too bad that i didn't knew about Ryu back than. as for roundtrips -- you're probably right. stb implementation was made to be "mostly correct", afair, but not fully correct. or i broke something (which is very possible). it worked for my cases, tho, so i just sticked with it. anyway, two is better than one! ;-)
Re: now it's possible! printing floating point numbers at compile-time
Stefan Koch wrote: Hi Guys, during my research on floating point numbers I came across a short and efficient implementation[0] of the grisu2 algorithm for converting floating point numbers into strings. Which I then ported into CTFEable D code. Thus enabling you to convert doubles into strings at compiletime. Cheers Stefan Koch P.S. You can find it at my fork of fpconv[1]. [0] https://github.com/night-shift/fpconv [1] https://github.com/UplinkCoder/fpconv/blob/master/src/fpconv_ctfe.d of course, it is not all that fancy, but i ported STB converter quite a long time ago, and it is ctfe-able too. ;-) [0] https://repo.or.cz/iv.d.git/blob_plain/HEAD:/ctfefloat.d
Re: libfirm-d - D bindings of Firm, a compiler IR based on the SSA form
Basile B. wrote: On Sunday, 1 July 2018 at 15:03:30 UTC, ketmar wrote: Basile B. wrote: I've recently ported libfirm to D. great news and great work, thank you. yet i must admit that wrapping != porting. Right, i have used the wrong words. Title hopefully is not ambiguous. ah, tbh, i'm just being jealous. you did my work! me is useless now!
Re: libfirm-d - D bindings of Firm, a compiler IR based on the SSA form
Basile B. wrote: On Sunday, 1 July 2018 at 15:03:30 UTC, ketmar wrote: Basile B. wrote: I've recently ported libfirm to D. great news and great work, thank you. yet i must admit that wrapping != porting. for a moment you made my heart stopped, 'cause i thought that i wasted alot of time trying to do a proper port (nope, not finished, but still...). Thanks. BTW I remember you said on IRC that SSA form is much better (maybe it was once when we talked about DMD optimizations or something like that)... this is basically why i choose this one, although not sure if i'll manage to do something with it. tbh, i gave up on porting it fully, so i prolly will go with your wrapper, if anything. and yeah, SSA rox. i am temporarily on C++ side now, yet sooner or later i'll return, and will have to restart Aliced again. maybe this time with a brand new backend. ;-)
Re: libfirm-d - D bindings of Firm, a compiler IR based on the SSA form
Basile B. wrote: I've recently ported libfirm to D. great news and great work, thank you. yet i must admit that wrapping != porting. for a moment you made my heart stopped, 'cause i thought that i wasted alot of time trying to do a proper port (nope, not finished, but still...).
Re: D IDE Coedit 3.6.7 - now with an integrated terminal emulator.
Basile B. wrote: I hadn't announced the 5 or 6 latest releases (3.6.x series) but this one comes with an integrated terminal emulator (linux only), a bit like Geany does, if you see what i mean. See https://github.com/BBasile/Coedit/releases for changelog and download links. yay!
Re: The Expressive C++17 Coding Challenge in D
Seb wrote: Someone revived the Expressive C++17 Coding Challenge thread today and I thought this is an excellent opportunity to revive my blog and finally write an article showing why I like D so much: https://seb.wilzba.ch/b/2018/02/the-expressive-c17-coding-challenge-in-d It's mostly targeted at beginners as I explain many basic D features, but maybe it's helpful for beginners looking into D. a typo: writefln!"%d"(foo"); it should be `"foo"`, i guess. ;-) great article. now i want to learn D again, it looks so beautiful and powerful! ;-)
Re: D's Newfangled Name Mangling
Andrej Mitrovic wrote: ah, 'cmon, we can hash the whole source file! let's move build system's work to linker! ;-) sorry, but this is really overkill. tracking changed files and rebuilding 'em on demand is something your build system should do.
Re: A list of all the awesome people who made D possible
great. yet i think that the page should note that people are listed in alphabetical order, not in any "importance" order.
Re: remake of remake of Konami's Knightmare
Taylor Hillegeist wrote: On Monday, 11 December 2017 at 19:34:56 UTC, ketmar wrote: major update: entity logic is completely driven by external ... you're welcome to study MES compiler implementation if you like. it is contained in one file (mesengine.d), and is not that hard to follow. I hope you didn't write that all in one sitting, I thought it was going to be a bit shorter. i am not even finished! actually, here[0] is the main repository for MES developement. you can track my progress there, starting from the very first commit. it doesn't meant to be public, tho, hence it is marked "OBSOLETE". [0] http://repo.or.cz/mes.d.git
Re: remake of remake of Konami's Knightmare
major update: entity logic is completely driven by external scripts now! ;-) most of "monsters.d" code moved to MES scripts. also, entity (actor in the terms of the engine) management was completely rewritten, so it mostly doesn't allocate in game loop. "what is MES?", one may ask. ok, MES is a scripting engine, writen specifically for scripting simple games. it has only one object type (Actor), but it is statically typed, supports UFCS and function pointers (and some syntactic sugar), so it may look like procedural or OOP language (at your choice). it is compiled to virtual machine code (3-operand instructions). compiler doesn't use AST, but does one extra pass over a source to collect functions/globals/fields definitions, so there is no need to write any forward declarations. so why i did it, and why it is better than old D code? the answer is very simple: because i can! ;-) you're welcome to study MES compiler implementation if you like. it is contained in one file (mesengine.d), and is not that hard to follow.
Re: remake of remake of Konami's Knightmare
Mengu wrote: On Tuesday, 28 November 2017 at 07:47:14 UTC, Nick Sabalausky (Abscissa) wrote: On 11/24/2017 08:28 PM, ketmar wrote: quickfix. forgot to properly set requested OpenGL version. http://files.catbox.moe/lx02hz.7z Very cool! Works under wine for me. Not a game I was familiar with, so it's cool learning hands-on about more of Konami's back catalog from one of the best gaming eras. chrome starts the download and then prevents it. would it be because if 7z? this. or, maybe, "catbox.moe" is "bad site" in some chrome filter. sorry, i don't know.
Re: remake of remake of Konami's Knightmare
Nick Sabalausky (Abscissa) wrote: On 11/24/2017 08:28 PM, ketmar wrote: quickfix. forgot to properly set requested OpenGL version. http://files.catbox.moe/lx02hz.7z Very cool! Works under wine for me. Not a game I was familiar with, so it's cool learning hands-on about more of Konami's back catalog from one of the best gaming eras. thank you! then you prolly can try this remake too: http://www2.braingames.getput.com/mog/default.asp this is Knightmare 2: a very different style, but great still great game. p.s.: the same codebase is working with GNU/Linux too. just rdmd it, with the proper -I settings. tnx to iv.vfs and arsd.sdpy, the code itself doesn't care about underlying OS. ;-)
Re: remake of remake of Konami's Knightmare
quickfix. forgot to properly set requested OpenGL version. http://files.catbox.moe/lx02hz.7z
Re: remake of remake of Konami's Knightmare
latest binary. some fixes, nicer title screen, alt now shoots too... http://files.catbox.moe/k7xxn0.7z
Re: remake of remake of Konami's Knightmare
bauss wrote: On Thursday, 23 November 2017 at 12:18:38 UTC, ketmar wrote: recently i worked on remake of DOS remake of Konami's Knightmare game[0]. the game is playable now, it has music from original MSX Knightmare, and sfx/gfx/levels from DOS remake. it is written in D, of course, and it is FOSS. you can find the sources here[1]. [...] This is pretty neat, good job! thank you!
Re: remake of remake of Konami's Knightmare
Martin Drašar wrote: Neat! Instead of working, I was spamming shift like crazy... glad that you liked it! this little thingy is very addictive. ;-) Now, when you say a partial port, did you make some automated translation or it is just a manual labor with lotta love? fully manual work. ah, except some simple regexps to replace "=" to "==", ":=" to "=" and such. i ported all monster and movement logic, and wrote new video, audio and game state management subsystems from scratch.
remake of remake of Konami's Knightmare
recently i worked on remake of DOS remake of Konami's Knightmare game[0]. the game is playable now, it has music from original MSX Knightmare, and sfx/gfx/levels from DOS remake. it is written in D, of course, and it is FOSS. you can find the sources here[1]. as usual, you'll need my IV modules[2], and Adam's ARSD modules[3]. the code won't work on 64-bit arches, tho (due to some bugs in sdpy/iv). but it can be compiled for 32-bit GNU/Linux, and 32-bit windows. here is windows binary for those who cannot (or don't want to) build the binary[4]. WARNING! the code is a partial port of old DOS turbo pascal sources, so it is *very* far from something even remotely sane. it is not polished yet, but that should not stop you! play this excellent classic shooter while it is hot! ;-) some tech info: arsd.simpledisplay is used for video (with OpenGL backend), arsd.simplesound for audio (with my AY-8910 emulator), iv.vfs for VFS support. as the game designed for 20 FPS, i didn't bother avoiding GC (that is, the engine allocates like crazy). enjoy, and happy hacking! [0] https://en.wikipedia.org/wiki/Knightmare_(1986_video_game) [1] http://repo.or.cz/knightmare.git [2] http://repo.or.cz/iv.d.git [3] https://github.com/adamdruppe/arsd [4] http://files.catbox.moe/z19j91.7z
Re: sample collaborative notepad implementation
Mengu wrote: dude, didn't know you were sitting on a gold mine (iv). thanks for sharing! you're welcome. if you need something other than GPL on some modules, this is usually negotiable (for free ;-).
sample collaborative notepad implementation
in the wootedit repo[0] you can find a very simple (but working) collaborative notepad implementation, based on WOOT algorithm[1][2]. if you ever wanted to know how all those collaborative editors were done... look no further! ;-) wootedit is simple, but complete implementation of such editor, with UDP-based network communication. currently, it was tested under GNU/Linux only, but there are no platform-specific code (except some socket API), so porting it to another OS should be trivial. you will need IV[3] and ARSD[4] libraries to build wootedit. [0] http://repo.or.cz/wootedit.git [1] http://hal.inria.fr/inria-00071240/ [2] https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type [3] http://repo.or.cz/iv.d.git [4] https://github.com/adamdruppe/arsd
Re: Life in the Fast Lane (@nogc blog post)
Guillaume Piolat wrote: On Saturday, 17 June 2017 at 13:05:50 UTC, Adam D. Ruppe wrote: This is why I consider @nogc to be an *extremely* niche feature and generally harmful. It makes things look a lot harder than it really is - people confuse `@nogc` with "no gc". Instead, I suggest just minding the list and using runtime profiling and debugging to ensure your needs are met in actual practice. As a counterpoint: It's true that it's a bit niche, but when you have "no gc" then @nogc really helps with peace of mind (only one allocation and you may crash). yeah, it helps a little... in (let's be honest) rare situations where you really want to be *completely* free of any possible gc allocation. in most real-life scenarios you're ok with "mostly gc-free, except for exceptional cases" (like writeln, for example), and you have no way to express it. i end up not using @nogc at all (except on simple `return a` getters), despite the fact that many of my code rarely allocates. there should be a way to say "i don't want gc on this code path, but it is ok for this one" (like throwing), without resorting to dirty tricks with casting and lambdas. something like `@raregc` ;-). but then, how we should define "rare"? that attribute will quickly become useless, as people will mark arbitrary code with it. so, `@nogc` is mostly useless IRL (you can't even `enforce` with it), and `@raregc` will become useless if introduced. and the sole reason (as i see it) of introducing `@nogc` was to please people complaining about gc allocations, no matter how often they're done, and on which code path. i myself see it as "PR design", which attracts people only to make them find that using D with `@nogc` is a PITA, due to `@nogc` being too restrictive. what `@nogc` *really* does now is dividing codebases into "i will do all kind of dirty tricks to avoid GC at all costs, even if it is not really necessary", and into "ah, screw it, i don't care". to me, it looks like `@nogc` does more bad than good now.
Re: Compile-Time Sort in D
Steven Schveighoffer wrote: At least in terms of i/o printing to the console or whatnot, it would be cool to be able to do so at compile-time just directly with writeln. As of now, a CTFE function can't call writeln, and it also can't pragma(msg, ...) because it has to be written as a runtime function. yeah, `ctfeWriteln()`, even in very rudimentary form, will be priceless for debugging CTFE code. sure, CTFE code can be called in runtime and debugged, but sometimes it require alot of bouncing back and forth, like "let's replace all `enum` values with `auto` down the code, and then back", 'cause result of one CTFE call may be used in another CTFE call, and so on...
Re: DIP 1003 (Remove body as a Keyword) Accepted!
Petar Kirov [ZombineDev] wrote: Personally, making contracts less verbose and more powerful is much higher on my list (I don't remember ever needing to use 'body' as an identifier, but I see why is it important for many domains) yeah. i'm really tired to use `flesh` instead of it. and i have bodies literally everywhere: active, sleeping, dead, broken... several of my game engines has more-or-less physics-based simulations, so i need `body`! ;-)
Re: DMD now has colorized syntax highlighting in error messages
Walter Bright wrote: https://github.com/dlang/dmd/pull/6777 It turned out to be unexpectedly easy to implement. The only downside is now we have to rather tediously tweak the error message texts so they use backticks. sorry for being rude, but this is exactly the example of things programmers like to write: fun, quite easy, and absolutely useless. most of the time it will be filtered away by ide/editor, and otherwise it is *harder* to read, 'cause it will almost certainly not match editor's syntax coloring settings, so reader will have to mentally strip the colors first. while much harder task -- showing which exactly template failed in template constraint -- is very hard to implement (i tried it, i know it), but will immediately benefit *anyone*, and will be really useful. i'm not trying to say that you should drop the things you like to work on, and switch to the things i like, of course. but this patch, IMO, doesn't deserve a dedicated NG post. sorry again, i'm frustrated by dmd inability to generate valid .o file from completely valid source, so can be harsh today.
Re: dmd Backend converted to Boost License
Jack Stouffer wrote: On Friday, 7 April 2017 at 15:14:40 UTC, Walter Bright wrote: https://github.com/dlang/dmd/pull/6680 Yes, this is for real! Symantec has given their permission to relicense it. Thank you, Symantec! Something that just popped into my head: You've said that you've avoided ever looking at other compiler's code to avoid legal trouble. Is that problem gone now? nope. GPL programmers can safely look into BSDL code, for example, 'cause it is ok to put GPL alongside of BSDL. but BSDL programmers can't "just take" GPL code. that is, it is prolly nobody will sue Walter for "copying GPL code", but it is better to be safe than sorry. this is how i see the things, of course, it's not the authoritative answer.
Re: dmd Backend converted to Boost License
Walter Bright wrote: Note that this also resolves the long-standing legal issue with D's inline assembler being backend licensed, and so not portable to gdc/ldc. yay!
Re: dmd Backend converted to Boost License
Walter Bright wrote: https://github.com/dlang/dmd/pull/6680 Yes, this is for real! Symantec has given their permission to relicense it. Thank you, Symantec! i don't even know what to say... thank you! i didn't even hoped that this will happen. what a glorious day today.
Re: Amper audio player for GNU/Linux and X11
some updates: * region.txt support for skins; * reworked equalizer (smaller, faster); * background scanner for playlist items (Amper won't hang when adding alot of files to playlist anymore); * ID3v2 parser, so mp3s will have (some) metainfo too; * fully configurable global hotkeys (including hotkeys for playback control); * better on-the-fly skin reloading; * pure X11 renderer, so Amper is using much less memory now.
Re: Amper audio player for GNU/Linux and X11
fixed some issues with 64bits compilation. tnx, NotSpooky! yet it is not possible to build 64bit Amper due to dmd bug: Error: undefined identifier '__va_list_tag' yes, exactly like that: no error line, nothing more. sorry, i don't have 64bit system, so i cannot do much with that. i tried some obvious workarounds, but without any success. 32bit ftw!
Re: Amper audio player for GNU/Linux and X11
ketmar wrote: if you have all the pathes set right, "rdmd amper.d" will start Amper. quickfix: "rdmd -J. amper.d" ;-)
Re: Amper audio player for GNU/Linux and X11
Guillaume Piolat wrote: There is a crazy amount of work here. Congrats ketmar. I've always been curious of what Amper looked like! tnx. it will be even more impressive with equalizer UI finished! ;-) there is no documentation on Amper console commands, but i can secretly tell you that user is able to change the skin without restarting Amper, for example. and do alot of other things (including equalizer control), which are impossible to do from UI yet. ;-) tbh, Amper is not that complicated: it mostly using already written libraries. most of the Amper code was done in three days, 'cause i already have console audio player, and ALSA backend. Adam's excellent simpledisplay.d took care of low-level window manipulation tasks (and image loading).
Re: Amper audio player for GNU/Linux and X11
Claude wrote: On Friday, 17 March 2017 at 06:33:38 UTC, ketmar wrote: * pure D audio code, no external decoder libraries required (and no SDL); * supports FLAC, Vorbis, Opus, MP3 playback; * various hardware sampling rates with transparent resampling of source audio; * multiband equalizer (the code is there, but UI is not ready yet); So you ported the FLAC, OPUS and MP3 decoder to D ? That's huge. :) yep. and two Vorbis decoders: stb_vorbis and Xyph's Tremor. Amper is using Tremor. sure, i cheated a little: FLAC decoder is standalone dr_flac library, and Opus was ripped from ffmpeg (and the code is awful). but hey, it works! ;-) mp3 decoder is originated in ffmpeg too. it was extracted to minimp3.c library by i-forgot-who, and then i ported it to D.
Amper audio player for GNU/Linux and X11
first, this is a weekend project to improve the underlying libraries, not a rival for existing audio/media players. yet it still may be of some interest. Amper is a WinAMP2/XMMS insipred player, with WinAMP2/XMMS skin support. it is using X11 for UI and ALSA for sound output. some ineresting features of Amper are: * pure D audio code, no external decoder libraries required (and no SDL); * supports FLAC, Vorbis, Opus, MP3 playback; * various hardware sampling rates with transparent resampling of source audio; * multiband equalizer (the code is there, but UI is not ready yet); * font rendering via FreeType, and font selecting via fontconfig; * reading skins directly from zip archives via iv.vfs library; * windowing via arsd.simpledisplay library; * CLI control utility (using simple RPC library iv.ncrpc); * notification area icon with hint window; * sound playback is done in background thread (std.concurrency rox!); * other k00l things i forget. screenshot: [0] Amper repo: [1] IV repo (required to build Amper): [2] ARSD repo (required to build Amper): [3] if you have all the pathes set right, "rdmd amper.d" will start Amper. as this is very WIP, you can't add files to playlist from UI yet (lol), so you have to pass 'em at command line, like this: rdmd amper.d mymusic.opus WARNING! this is *WIP* code. many features are missing, and there are alot of bugs. yet Amper already can play music, and you can control it (to some extent) with a mouse. please, don't report bugs, as i probably already know about 'em (but tnx for trying). i'm announcing the project at this early stage to show that D can be used for "serious programs", including decoding various complicated audio formats and DSP processing, and for writing "fancy" UIs. please note that arsd.simpledisplay supports windows too, this is just my code that doesn't (but i'll eventually fix it, so Amper will be able to work on windows). also please note that Amper is not a frontend to some existing audio decoding/playback library, all audio processing is done with D! you will prolly need dmd 2.073.2 to build Amper (lower versions not tested). skin credits: PipBoy2000 by Gerko. p.s.: press ctrl+q to quit Amper. ;-) p.p.s.: please, no reddit/lobsters/slashdot/etc. [0] http://files.catbox.moe/y5wtak.png [1] http://repo.or.cz/amper.git [2] http://repo.or.cz/iv.d.git [3] https://github.com/adamdruppe/arsd.git
Xiph's Ogg/Opus decoder
i said that i won't do Opus port, so of course i did it[0]. this is preliminary release, it works on some Opus files i have (and some i made with ffmpeg). there will be some improvements, but the code is already usable. it decodes mono or stereo ogg/opus streams to interleaved 16-bit pcm. the code itself was taken from ffmpeg and massaged until it works. no attempts to clean it up or something were made, sorry. ogg parser was written from scratch. you will need my iv.vfs too. GNU LGPL. good luck, and happy hacking. [0] http://repo.or.cz/iv.d.git/tree/HEAD:/dopus
Re: New GDC binaries: 2.068.2, shared library support, multilib support & a new gdmd tool
On Sunday, 25 December 2016 at 19:41:38 UTC, Johannes Pfau wrote: Happy holidays everybody, great work! long live gdc! ;-)
Quick-and-Dirty Xiph Tremor decoder port
here[1] is $subj. it is as close to the original C source as possible. it also includes partial vorbisfile port, so it is completely self-contained and doesn't require any C library besides libc. there is also sample ALSA player[2]. it requires ALSA bindins[3]. grab it now while it's hot, 'cause i will probably mutilate it later. so if you want almost 1:1 C port... hurry up! the time is short! p.s.: it compiles for x86_64 arch, but i didn't tested if it really works with 64 bits. p.p.s.: why? because i can. and no, i won't port Opus decoder. at least not for free. ;-) [1] http://repo.or.cz/iv.d.git/blob_plain/HEAD:/xogg/tremor.d [2] http://repo.or.cz/iv.d.git/blob_plain/HEAD:/xogg/trest.d [3] http://repo.or.cz/iv.d.git/blob_plain/HEAD:/alsa.d
Re: Milestone - DMD front end is now 100% D!
ACHIEVEMENT UNLOCKED!
Re: simple VFS implementation
contrary to what i said ealier, there is now a way to get list of known files, with their times and packed size (if containter supports that feature). zip reader now understands all standard zip methods (including "shrink", "reduce" and "implode"), and LZMA (no external lzma library required). currently there are no plans to support BZip2 and PPMd compression. internal structures creates less pressure on GC and way less false positives: instead of registering the whole allocated memory "just in case", getPointerBitmap is used to register only pointers. and many internal structs doesn't have GC pointers at all. added iv.vfs.io module, so it is possible to use good old `write*`, `readf`, `readln` API on VFile. it also wraps standard input and output, so to do console i/o you now can import iv.vfs.io instead of std.stdio. there is also `byLine` and `byLineCopy` API. not a speed demon, tho, so i'd not try to process terrabytes of text data with it. added zip creation module. not really new, but worth mentioning anyway: there is nice API to read/write endianness-neutral numeric values. readNum!T and writeNum!T. and `rawReadExact()` low-level API, to read the whole buffer or throw. added Ken Silverman's GRP support. i had to mention it somewhere.
Re: Box2D Lite D Port (Yet Another)
On Monday, 31 October 2016 at 13:40:38 UTC, John Colvin wrote: If you could put up with putting each file (or maybe group of files that might form one dub package) in to a separate folder, add a dub.sdl for each folder, put a single dub.sdl in the root folder with all the other folders listed in it as subPackages, then push the whole thing to bitbucket, register on code.dlang.org and you're done? If you really don't like having all those folders you could easily create a script to move everything in to place. Could even be in a git hook! that's not something i'd call "non-intrusive". ;-)
Re: Box2D Lite D Port (Yet Another)
On Monday, 31 October 2016 at 09:22:22 UTC, Martin Drašar wrote: Neat! Not that I need a physics engine right now, but it is always good to have implementation of some structures at hand. thank you. Anyway, tht Invisible Vector project of yours, is it a collection of useful stuff like Adam's arsd, or is some standalone project? it is like Adam's arsd: a collection of random things. basically, when i need something for one of my projects, i'm going to steal/implement it "in-place" (i.e. in project source tree), and later i may see that implementation as a good thing to share between other projects. at this stage i'm doing some more work on it, and then moving it in IV. and even if it won't be shared between projects, i sometimes moving it to IV just to have it everything in one place. ;-) I am asking, because it seems to contain some nice things (like a sat solver port) that may help others and could benefit from being more accessible than only with a programmer's spelunker gear. And I am saying this with full knowledge of your passionate hate for github and to some extent for dub. i investigated the possibility of having IV as collection of DUB projects (again), and it is still too intrusive. alas. actually, i'd like to feature IV as a set of libraries with dependencies on code.dlang.org, so people can easily use 'em, but DUB isn't very tolerant to things that aren't done in "DUB way". i am really saddened by that, but i have no desire to work on DUB, neither to "dubify" my workflow. i'm trying to help those who wants to use my code, tho. ;-) i'm usually available on IRC. p.s. to keep it all somewhat on-topic: if someone wants to add more joint types, it is possible to take 'em from Chipmunk code, almost unmodified. Chipmunk is using basically the same integration scheme (preStep/applyImpulse), so you'd have to do some simple renamings (cpFloat -> VFloat, etc.), and replace Chipmunk's vector math with iv.vmath. i deliberately avoied doing that to keep the code small (and to not spoil the fun of turning something simple to something more powerful ;-).
Box2D Lite D Port (Yet Another)
hi. i was in need of very simple (yet usable for something more than "hey, this is how Big Players doing physics!") 2d physics engine for some of my pet projects, and i decided to use Box2D Lite as base (mostly 'cause it has simple joints implemented). so i ported it, mutilated it and had it working in less than 40 kb of source code. so far, so good. but suddenly... but suddenly i realised that B2DL can operate only on boxes (no other body shapes were implemented), and it has O(N^2) broad phase. of course, this is perfectly fine for a demo purposes, but little limiting for my projects. so after mutilating the patient, i surgically enhanced it a little[1]. now my port supports the following features: * convex polygonal bodies with different density * SAT collistion detection * hard and soft joints * friction * O(N*logN) broad phase * source size is still ~65 KB this is not a finished physics engine, of course, and you will have to do some more work to make it usable in real apps (like adding contact callbacks, for example), but it can give you something you can start with, still not really hard to follow, but more complete than original Box2D Lite. among other things my port has (almost) standalone implementation of Dynamic AABB Tree, which powers new broad phase. even without further optimizations (like frozen bodies), it allows me to process 1100 bodies in less than 30 milliseconds. don't even try that with O(N^2) broad phase! ;-) even if you aren't interested in physics engine per se, you can rip (and tear ;-) this implementation and use it in your projects. any project that needs some form of fast spatial selection (either 2D or 3D, the implementation supports both) can benefit from using dynamic balanced trees for that. it is based on "real" Box2D AABB Trees, and is fairly efficient (and taken from another project too ;-). it is using malloced pool of nodes internally, so it should be suitable for nogc realtime rendering. you will need my iv.vmath[2] library for vector math. physics library doesn't draw anything on it's own, but the sample does, so it requires my iv.glbinds[3] and simpledisplay from Adam's arsd[4]. the code itself is not the cleanest one, but it is still readable (i hope), and should be easy to follow and modify. good luck and happy hacking! p.s. it looks like Chipmunk library has the same origins (and genesis, at least to some extent ;-). [1] http://repo.or.cz/b2ld.git [2] http://repo.or.cz/iv.d.git/blob_plain/HEAD:/vmath.d [3] http://repo.or.cz/iv.d.git/tree/HEAD:/glbinds [4] https://github.com/adamdruppe/arsd
Re: Project Highlight: Timur Gafarov
On Friday, 16 September 2016 at 14:12:49 UTC, c-v-i wrote: On Friday, 16 September 2016 at 12:53:44 UTC, Mike Parker > can someone build atrium ? i did it several times, even without dub.
Re: DlangUI 0.9.0: Console backend added
On Wednesday, 14 September 2016 at 13:04:40 UTC, ketmar wrote: in my editor i'm simply using rgb in [0..255] range, and mapping that to what terminal has. yet it is probably not the best way to make something nice looking when only 16 colors are available. heh, i should try and see how it will look like! ;-) actually, it's not that bad, i expected much worser results. original 256 color mode: http://ketmar.no-ip.org/img/tui/tui_c256.png and this is restricted to basic 16 colors: http://ketmar.no-ip.org/img/tui/tui_c16a.png still readable. my terminal has somewhat non-standard first 16 colors (some colors are brighter than default xterm, some are not), that's probably why background becomes so bright. but it is still readable. and this is 16 colors with "weighted translation" (0.30*r+0.59*g+0.11*b). looks surprisingly clean: http://ketmar.no-ip.org/img/tui/tui_c16b.png
Re: DlangUI 0.9.0: Console backend added
On Wednesday, 14 September 2016 at 13:08:18 UTC, Rory McGuire wrote: Screenshots here are what can be done with terminal/ascii: http://caca.zoy.org/wiki/libcaca still, you can't use shading charaters to color text, so 16 colors for text output won't look that impressive. ;-)
Re: DlangUI 0.9.0: Console backend added
p.p.s. yep, VT-100 had only 4 functional keys, so we still enjoying having 'em encoded separately from the others.
Re: DlangUI 0.9.0: Console backend added
On Wednesday, 14 September 2016 at 13:04:40 UTC, ketmar wrote:
On Wednesday, 14 September 2016 at 05:58:51 UTC, Vadim Lopatin
CSI-with-modifier codes: \e[1;
this is common format for keys with modifiers, actually. let me
quote my rawtty2:
bool xtermMods (uint mci) @nogc {
switch (mci) {
case 2: key.shift = true; return true;
case 3: key.alt = true; return true;
case 4: key.alt = true; key.shift = true; return true;
case 5: key.ctrl = true; return true;
case 6: key.ctrl = true; key.shift = true; return true;
case 7: key.alt = true; key.ctrl = true; return true;
case 8: key.alt = true; key.ctrl = true; key.shift = true;
return true;
default:
}
return false;
}
void xtermSpecial (char ch) @nogc {
switch (ch) {
case 'A': key.key = TtyKey.Key.Up; break;
case 'B': key.key = TtyKey.Key.Down; break;
case 'C': key.key = TtyKey.Key.Right; break;
case 'D': key.key = TtyKey.Key.Left; break;
case 'E': key.key = TtyKey.Key.Pad5; break;
case 'H': key.key = TtyKey.Key.Home; break;
case 'F': key.key = TtyKey.Key.End; break;
case 'P': key.key = TtyKey.Key.F1; break;
case 'Q': key.key = TtyKey.Key.F2; break;
case 'R': key.key = TtyKey.Key.F3; break;
case 'S': key.key = TtyKey.Key.F4; break;
case 'Z': key.key = TtyKey.Key.Tab; key.ch = 9; if
(!key.shift && !key.alt && !key.ctrl) key.shift = true; break;
default: badCSI(); break;
}
}
Re: DlangUI 0.9.0: Console backend added
On Wednesday, 14 September 2016 at 05:58:51 UTC, Vadim Lopatin wrote: Thank you! Now dlangui terminal mode supports only 16 colors. Some refactoring is required to support RGB colors. in my editor i'm simply using rgb in [0..255] range, and mapping that to what terminal has. yet it is probably not the best way to make something nice looking when only 16 colors are available. heh, i should try and see how it will look like! ;-) On Wednesday, 14 September 2016 at 06:06:51 UTC, Vadim Lopatin wrote: at least in Gnome terminal. maybe gnome terminal took those keys for it's own needs -- like tab switching or something. in xterm, those are usual CSI-with-modifier codes: \e[1;, where is 6 for ctrl+shift, and is A/B/C/D for Up/Down/Right/Left respectively. it is better to check everything in xterm -- this is still the most used terminal emulator out there. just switch it to send for alt-key instead of setting high bit. ;-)
Re: DlangUI 0.9.0: Console backend added
On Tuesday, 13 September 2016 at 12:29:47 UTC, Vadim Lopatin wrote: Screenshots on imgur: http://imgur.com/a/eaRiT btw. please note that on most GNU/Linux terminals you can use simple RGB colors (with each component in [0..5] range). IRL if $TERM != "Linux", it is safe to assume that terminal supports 256 colors (with rare exclustions like "screen" -- those can be safely ignored, screen is fubared anyway ;-).
Re: DlangUI 0.9.0: Console backend added
On Friday, 9 September 2016 at 12:52:35 UTC, Vadim Lopatin wrote: Thank you! I'll look at it. feel free to ping me on IRC if you'll have any questions.
Re: DlangUI 0.9.0: Console backend added
On Friday, 9 September 2016 at 12:20:08 UTC, Vadim Lopatin wrote: Keyboard support on Linux terminals seems most difficult. Some shortcuts are being processed by terminal app. here programmer has no options. Some ctrl-combinations are causing signals. switch tty to raw mode, and there will be no signals. see my iv.rawtty2, for example. E.g. I cannot get working text selection moving by Ctrl+Shift+Arrows. this is hightly dependent of the actual terminal emulator. in real world, it is enough to support xterm mappings, rxvt mappings and "Linux" (this is "real" console) mappings. xterm and rxvt mappings aren't really conflicting (much). again, the messy iv.rawtty2.ttyReadKey may give some clues. of course, "best practice" is to use termcap/terminfo, but this is even bigger mess! ;-)
Re: Beta D 2.071.2-b3
On Friday, 2 September 2016 at 08:57:14 UTC, Basile B. wrote: On Friday, 2 September 2016 at 08:15:53 UTC, ketmar wrote: std.traits wrappers should use __traits to build *safe* things (declaring that @trusted in the end). This has nothing to do with memory safety. i wonder who told you that @safe code is *only* about "memory safety".
Re: Beta D 2.071.2-b3
On Friday, 2 September 2016 at 07:46:30 UTC, Rory McGuire wrote: actually, from my PoV solution is supereasy: just remove ALL visibility restrictions for traits. and i mean all. allMembers should return all members, getMember should allow to access *any* existing member without annoying messages. it is up to programmer to insert getProtection checks if he needs it. traits is a low-level feature by definition, and doesn't meant to be used directly (we have std.traits wrappers for that), so i want D devs to stop making our, low-level coders, life harder than it is now. ;-) D devs just should draw the line between __traits and std.traits. first sould be inherently unsafe, allow *everything* and impose as little restrictions as it is possible (note: *as* *possible*, not *as* *sane* -- all kind of insanity should be allowed, if it is possible). then, std.traits wrappers should use __traits to build *safe* things (declaring that @trusted in the end).
Re: Beta D 2.071.2-b3
On Friday, 2 September 2016 at 06:27:11 UTC, Rory McGuire wrote: Perhaps @system code should just completely ignore privacy? it is uncontrollable. imagine attribute inference: today, your function was inferred @system, and it sees everything. and tomorrow you fixed some other things, and now your function inferred as @safe. BOOM! without warning, it doesn't do what it does before (but still works!), and you didn't even touched it's code. this is the worst kind of breakage. Could have a compiler option that changes the access errors into warnings? each compiler option of this kind means "we failed our design task, brought you the feature that is so unusable that we even made it possible to turn it off globally. sorry, we giving up, now it is up to you to clean up the mess after us."
Re: Beta D 2.071.2-b3
On Tuesday, 30 August 2016 at 23:54:45 UTC, Martin Nowak wrote: Allowing access to private members has a lot of implications, e.g. breaks lots of optimizations b/c you can't know who accesses sth. i really HATE modern trend of turning tables. am i the only one who thinks that the machine was designed to serve the human, not vice versa? yet somehow we all trying to make our machines happy now, instead of using 'em. the most funny thing with it is that modern software is bloated, dog slow, resource hungry and barely usable. so all this "please the machine" movement is completely pointless!
Re: Beta D 2.071.2-b3
On Wednesday, 31 August 2016 at 05:23:34 UTC, ketmar wrote: On Tuesday, 30 August 2016 at 23:54:45 UTC, Martin Nowak wrote: As in needs private members in __traits(allMembers). and in the end it just producing excessive noise in common loops that does `is(typeof(__traits(getMember, ...)))`. it would be better to either leave that alone and allow all access, or exclude inaccessible members gin `allMembers` completely. yet D choose the third way, combining the worst features from both solutions. oops. seems that i did something wrong with myself. i'm sorry, the PR you linked seems to do exactly what i described. dunno how i managed to completely misunderstand it.
Re: Beta D 2.071.2-b3
On Tuesday, 30 August 2016 at 23:54:45 UTC, Martin Nowak wrote: As in needs private members in __traits(allMembers). and in the end it just producing excessive noise in common loops that does `is(typeof(__traits(getMember, ...)))`. it would be better to either leave that alone and allow all access, or exclude inaccessible members gin `allMembers` completely. yet D choose the third way, combining the worst features from both solutions.
Re: simple sax-style xml parser
On Friday, 29 July 2016 at 14:47:08 UTC, Chris wrote: Thanks. I might actually use it. I need an XML parser and wrote a very basic and incomplete one for my needs. great. don't forget to get lastest versions from that links. and feel free to report any bugs here, i'll try to fix them asap. ;-)
Re: D-Man culture
On Wednesday, 27 July 2016 at 19:50:13 UTC, Walter Bright wrote: While I appreciate the effort and the offer, it is inappropriate to have a woman with a miniskirt and partially unbuttoned blouse as an official mascot for D. i agree. she has too much clothes on.
simple sax-style xml parser
i wrote a simple sax-style xml parser[1][2] for my own needs, and decided to share it. it has two interfaces: `xmparse()` function which simply calls callbacks without any validation or encoding conversion, and `SaxyEx` class, which does some validation, converts content to utf-8 (from anything std.encoding supports), and calls callbacks when the given path is triggered. it can parse any `char` input range, or std.stdio.File. parsing files is probably slightly faster than parsing ranges. internally it is extensively reusing memory buffers it allocated, so it should not create a big pressure on GC. you are expected to copy any data you need in callbacks (not just slice, but .dup!). so far i'm using it to parse fb2 files, and it parsing 8.5 megabyte utf-8 file (and creating internal reader structures, including splitting text to words and some other housekeeping) in one second on my i3 (with dmd -O, even without -inline and -release). it is not really documented, but i think it is "intuitive". there are also some comments in source code; please, read those! ;-) p.s. it decodes standard xml entities (
Re: NanoSVG port
also, i extended the original library a little: added rudimentary support for "style" tag and styling svg elements. nothing fancy, but many svgs found in internet are using that to avoid repeating "style" everywhere. it is a dirty hack (sorry), but makes even more svgs "renderable".
Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 16:52:09 UTC, Ola Fosheim Grøstad wrote: @tco does not bring any guarantees to the caller, so you might as well annotate the call-site with some compiler specific feature. actually, annotating the call itself seems to have alot more sense judging from described OP inspiration for the feature.
Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 11:17:17 UTC, ag0aep6g wrote: Your quote leaves out the "because" part, which is the interesting part. because it is irrelevant.
Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 10:50:20 UTC, "Smoke" Adams wrote: You are not i am.
Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 09:46:24 UTC, ag0aep6g wrote: So when one makes a post here saying that "D is aimed at brain-dead people", we shouldn't take that for an insult. absolutely. but "D is crap" is whole different story.
Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 09:24:58 UTC, ag0aep6g wrote: On 07/10/2016 08:39 AM, ketmar wrote: note that i didn't said this about OP, in no way. so no personal attacks here. It's no stretch to assume that the one who proposes the feature would make use of it. You called those who would use it "brain-damaged". i am not responsible for people's assumptions.
Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 09:05:46 UTC, Tofu Ninja wrote: Your joking right? No personal attacks? where do you see personal attack in my words? i'm not saying that OP is dumb, and i'm not saying that his proposal is dumb. but it is *aimed* to dumb people (which doesn't automatically makes it dumb, you know). and i got tired of being "polite", from now on when i'll see dumb people, i'll say that i see dumb people, not "different" or "mentally impaired". as for the topic, i *tried* to explain why i see no value in the proposal. and part of the explanation included referring to "brain-damaged coders". but yeah, this (again) reminded me why i once resigned from NG. i'd probably should do it again, IRC is enough.
Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 07:30:32 UTC, Dietrich Daroch wrote: If attributes look messy, pragma can be used. It may look as an addition with little gain, but one of the reasons of compiling is to prevent runtime errors as early as possible and this seeks exactly that. then TCO should be added to language spec too. for now, compiler is not obliged to implement it. also, many implementations only implement TCO for functions with exactly same args -- is this something that should be speced, or not? we already has one optimization case speced -- NRVO. and it is BAD. adding another implementation detail to the spec will only worsen the situation, i believe.
Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 06:44:22 UTC, Dietrich Daroch wrote: Yes, there is no cure for poor skills, but the point is to prevent the need to avoid recursion to ensure there are no stack overflows. It seems reasonable considering D targets systems programming. i see "system programmer" as someone who is able to understand when TCO is in effect without additional attribute noise. and for others it just doesn't matter -- as they probably is using a library written by "system programmer" anyway, and won't dive into code. ;-) sorry, it is really just a noise, like "@nogc". compiler does a fairly good work on TCO already, and adding another attribute will just make code messier. it is already @too @many @attributes @in @D.
Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 06:37:18 UTC, ketmar wrote: On Sunday, 10 July 2016 at 06:20:59 UTC, Seb wrote: ... guys, please stay friendly, constructive and polite! I thought we are all grown-ups here! i do. someone who is not able to understand when and how TCO works is clearly brain-damaged. if he isn't, why did he become programmer in the first place? it is clear that he is not able to program. note that i didn't said this about OP, in no way. so no personal attacks here.
Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 06:20:59 UTC, Seb wrote: ... guys, please stay friendly, constructive and polite! I thought we are all grown-ups here! i do. someone who is not able to understand when and how TCO works is clearly brain-damaged. if he isn't, why did he become programmer in the first place? it is clear that he is not able to program.
Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 05:55:50 UTC, Dietrich Daroch wrote: Yes, it probably does TCO. The problem is what if you think it does and it cannot do it because of a misunderstanding on when it can be applied or a bug? there can't be any "misunderstanding" from compiler side. either it is a leaf return, or not -- it is as easy as that. what your DIP is aimed for is brain-damaged coders who are not able to understand how programs work (and why "scope(exit)" may prevent TCO). it won't help anyone. sorry.
Re: NanoSVG port
just make sure to download the latest version by the given link before you want to try it. ;-) glad to see that you found it useful
NanoSVG port
i also made NanoSVG[1] port[2]: simple SVG parser and rasterizer. it is using `malloc()` to allocate memory, but otherwise was rewritten to use `const(char)[]` input for svg, and do not use `sscanf()` from libc. the port lives in NanoVG package, but it is actually completely independent. [1] https://github.com/memononen/nanosvg [2] http://repo.or.cz/iv.d.git/blob_plain/HEAD:/nanovg/svg.d
Re: Battle-plan for CTFE
p.s. it is, btw, completely possible to add at least something like "ctfe tracer" (something like old basic "trace on" command), or even some kind of gdb-like debugger to ctfe engine. it won't, of course, find it's way into mainline, but may still be a fun project to do.
Re: Battle-plan for CTFE
On Friday, 8 July 2016 at 23:31:38 UTC, Stefan Koch wrote: and mine is segfaulting in some bizarre ways (i failed my basic ++ and -- math, and so the stack ;-). still, it is almost working, with support for both compiled and interpreted function calls, almost full range of integer math and some string ops. druntime still compiles and passes unittests, but phobos segfaulted somewhere deep in my CTFE engine. i really need to re-check all added opcodes and codegen. writing that was surprisingly easy. and sometimes simply surprisingly: "how did you came to me with this, DMD?! eh? aha, i see now, thank you, grep." ;-) some stats: virtual machine is <30KB of code now. compiler is ~70KB, but there is alot of copypasta in there (you know, it happens when the code grows organically). if someone is interested in interop between frontend and backend, writing engine like this is a nice way to make yourself familiar, as CTFE interpreter effectively gets already semanticed AST, with most things correctly lowered and so on. so you only have to copy dummy CtfeCompiler from dinterpret.d (it only count vars there, otherwise doing nothing), and start extending it. even when we'll get new shiny engine from Stefan, i still recommend to anyone who wish to understand how compiled and processed code looks inside the frontend at least try to implement some simple bytecode compiler. with some care seeing that you are effectively replacing compiler parts, and it is still able to compile complex unittests is... yeah, go find the word. ;-)
Re: Battle-plan for CTFE
yay. ackemann(3, 7) in 70 milliseconds! and it does TCO. default interpreter is unable to execute that -- recursion is too deep.
Re: one-file pure D decoders for vorbis, flac and mp3
On Tuesday, 5 July 2016 at 09:04:38 UTC, sam wrote: This was the only way I could get it to compile on DMD64 D Compiler v2.071.1 / LDC - the LLVM D compiler (1.0.0). yep, i forgot to test it with 64-bit compiler, sorry. i fixed all three decoders now. There are a lot more errors in the gdc version mainly about pragma. yep, `pragma(inline, true);` is not supported by gdc yet. still, i added condition to all pragmas, so it should work with GDC now.
Re: Battle-plan for CTFE
just... can't... stop... some current statistics: druntime total interpreted calls: 27,146 total complied calls : 1,330 phobos total interpreted calls: 6,492,826 total complied calls : 19,975 i can't do function calls from compiled code yet, so number of compiled calls is low, and no speedup can be seen. also, i can do only integer math and string concatenation. yes, phobos has ALOT of CTFE! ;-) this is statistics from "make -f posix.mak unittest" (yes, i can pass all unittests too!) still, not that bad for a toy implementation! ;-)
Re: Battle-plan for CTFE
On Wednesday, 6 July 2016 at 08:16:32 UTC, Rory McGuire wrote: Thought as much, wondered if the ideas about how they work were being shared; often one idea sparks another. sure, some ideas flows; mostly very high-level. for example, proper fallback to the original interpreter was invented by Stefan, but i was faster to make it work. ;-) after all, we aren't competitors. he is still working hard on full implementation, and i am just having some fun, investigating creation of DMD backends by the way.
Re: Battle-plan for CTFE
On Wednesday, 6 July 2016 at 05:54:48 UTC, Rory McGuire wrote: Are you sharing this code i mean "my code is publicly available, but we aren't sharing any code between our projects".
Re: Battle-plan for CTFE
On Wednesday, 6 July 2016 at 05:54:48 UTC, Rory McGuire wrote:
Are you sharing this code
yes. we are chatting with Stefan in IRC, and the repository is
public (i mean, the link was there ;-). yet it won't compile with
"vanilla" dmd anyway -- i require my dmd fork ("aliced"). and i
don't really want to make it more public, as i have no intentions
to turn that into full-blown engine.
also, not only our codebases are completely different, but our
designs and approaches are drastically different. we just can't
share/reuse the code, those projects are as compatible as WLIV
and Z80. ;-)
how you did it with the GSOC intern?
Stefan in not GSOC intern. ;-)
Re: Battle-plan for CTFE
and just to make sure that my approach is working: bytecode compiler now compiles simple free functions without args and returning int (yep, there are some in phobos! ;-), while passing everything other to old interpreter. it works, and all phobos unittests are passed (and some functions were actually executed with VM). that's where i should stop, i think, until it comes too far. ;-)
Re: Battle-plan for CTFE
On Monday, 4 July 2016 at 07:33:48 UTC, ZombineDev wrote: BTW, do you plan to handle stuff like exceptions, virtual calls and associative arrays and if so how? Sounds quite challenging. on the lower level, it's all just arrays and jumps. ;-)
Re: Battle-plan for CTFE
so, we played a little game with Stefan: i wrote a simple stack-based VM implementation for our beloved bug6498, and got 270 msecs with debug build, 140 msecs with release build. can be made even faster with some simple peephole optimizer (it has two hacks to get fair times on 6498, but this is not a good peephole opt ;-). of course, it scales linearly too. don't expect me to join the race, though: i was just curious how well stack-based VM can do.
Re: one-file pure D decoders for vorbis, flac and mp3
On Monday, 4 July 2016 at 08:18:29 UTC, Basile B. wrote: On Monday, 4 July 2016 at 07:33:19 UTC, ketmar wrote: for me, test player is happy playing 7-Zip archives as mp3s, for example. ;-) lol, does that sounds like if an hard-knee compressor limits the output ? i'd say that it is like compressed industrial death metal.
Re: NanoVG and OUI ports
also, i'm slowly working on Yet Another Immediage GUI Library
based on Blendish and simplified flex box model.
for now, it can do layouting (with line wrapping, and determining
minimal window size) and has some basic controls, like buttons,
labels, checkboxes.
also, i changed NanoVG API a little. mostly got rid of `nvg`
prefix for functions accepting `NVGcontext*` ('cmon, we have
modules and UFCS in D!), and changed `NVGcontext*` arg to simply
`NVGContext` (note capital "C").
btw, it is GPLed now. bad news for GPL haters.
Re: one-file pure D decoders for vorbis, flac and mp3
On Monday, 4 July 2016 at 05:16:50 UTC, sam wrote: https://my.mixtape.moe/cjekko.mp3 pushed small update, it works now. i accidentally forgot to include ID3v2 tag skiping at all, sorry! ;-) thank you for report, feel free to report even more! ;-)
Re: one-file pure D decoders for vorbis, flac and mp3
On Monday, 4 July 2016 at 05:16:50 UTC, sam wrote: But I noticed that any MP3 with embedded album art is reported as invalid by the library. Here's a sample one: https://my.mixtape.moe/cjekko.mp3 yep, mp3 detection is very basic. while it *tries* to do some work on it, you'd better not rely on detection results. for me, test player is happy playing 7-Zip archives as mp3s, for example. ;-) thank you for report. i may do something to improve detection, but to be honest, it is not a priority. such one-file libs are usually used in environments where you know what your files are (like game engines and such). also, please, be aware that you *may* crash libs with malformed input data. while the libs trying their best to not fail, this is, again, not a priority. but still, i'm using my test player to listen my huge vorbis/flac/mp3 collection, and it seems to work most of the time. p.s. i'll take a look at the sample anyway. minimp3 should skip ID3 tags at the start of the file, but i didn't really tested that code.
Re: one-file pure D decoders for vorbis, flac and mp3
vorbis decoder synced with current stb version (1.06 -> 1.09)
Re: daffodil, a D image processing library
On Friday, 1 July 2016 at 01:47:44 UTC, Jack Stouffer wrote: Way to be a dismissive asshole. why so serious? it is clearly a joke.
Re: daffodil, a D image processing library
On Friday, 1 July 2016 at 01:24:55 UTC, rikki cattermole wrote: Doesn't use allocators great library! definitely worth a closer look.
NanoVG and OUI ports
yes, it's me again. hello. this time i ported NanoVG[1] drawing library (only OpenGL2 backend) and OUI[2] intermediate UI library. they require some modules from Adam's arsd library[3] to work -- mostly simpledisplay for screen setup and minimal OpenGL bindings, and arsd.png to load png images. one can also use my jpeg decoder to add jpeg support. ttf rendering powered by FreeType: feel free to take Derelict bindings, and change one import in "fontstash.d". this time the things are not single-file ports, though. have fun and happy hacking. ah, i forgot link to ports! here they are: NanoVG and OUI[4], demo[5]. p.s. default dmd flags does ~35 FPS on OUI sample. but dmd -O, even without inlining, does solid 60 FPS. [1] https://github.com/memononen/nanovg [2] https://bitbucket.org/duangle/oui-blendish/overview [3] https://github.com/adamdruppe/arsd [4] http://repo.or.cz/iv.d.git/tree/HEAD:/nanovg [5] http://repo.or.cz/iv.d.git/tree/HEAD:/nanovg_demo
Re: one-file pure D decoders for vorbis, flac and mp3
On Wednesday, 29 June 2016 at 18:03:50 UTC, deadalnix wrote: I did vorbis by myself in the past in java, that format is UUUGHH ! lucky me, Sean did all the hard work. ;-) Good work. thank you.
Re: one-file pure D decoders for vorbis, flac and mp3
On Wednesday, 29 June 2016 at 10:22:39 UTC, Martin Nowak wrote: Any chance you'll turn this into a dub package? zero. i'm not using dub, and i hate dub polluting my source directory with it's files. but i don't mind if somebody will just fork/take the sources and create dub packages from that (or any other source from IV one is interested in). no need to ask my permissions or something.
