[02:17:16 CEST] <alevinsn> what's the word I'm looking for? function A calls function B, and function B calls function C [02:17:30 CEST] <alevinsn> instead, take the call to function C and call it from function A after calling function B [02:17:46 CEST] <alevinsn> what's the word to describe extracting the function call to function C from function B and moving it to function A [02:17:47 CEST] <alevinsn> ? [02:18:02 CEST] <alevinsn> I know there's a word for that.... [02:40:03 CEST] <cone-983> ffmpeg 03Michael Niedermayer 07master:6b5d3fb26fb4: avcodec/webp: Always set pix_fmt [02:40:03 CEST] <cone-983> ffmpeg 03Michael Niedermayer 07master:60765cc42e3e: avcodec/pixlet: Fix runtime error: signed integer overflow: 436207616 * -5160230545260541 cannot be represented in type 'long' [02:40:03 CEST] <cone-983> ffmpeg 03Michael Niedermayer 07master:c0ece1f4addf: avcodec/mpeg12dec: Fixes runtime error: division by zero [02:52:27 CEST] <jamrial_> alevinsn: refactoring? idk [02:52:47 CEST] <alevinsn> I thought that might be it, but refactoring is a pretty broad term [02:52:54 CEST] <alevinsn> and covers a number of different techniques [04:16:40 CEST] <cone-983> ffmpeg 03Steven Liu 07master:7355c1dda2f8: avformat/hlsenc: move old_filename free operation earlier [04:24:50 CEST] <philipl> BtbN: I might be an idiot, but I don't actually see you calling decodePicture. [04:24:54 CEST] <philipl> That would explain the garbage :-) [04:25:35 CEST] <philipl> You go straight from av_hwframe_get_buffer to cuvidMapVideoFrame [08:52:38 CEST] <beandog> who do I have to bribe with cookies to help me figure out the new encoding api [08:52:43 CEST] <beandog> :) [08:53:17 CEST] <rcombs> it's reasonably simple [08:53:41 CEST] <rcombs> you send a frame, then receive packets until you get EAGAIN (usually you get one, but this can vary) [08:54:04 CEST] <beandog> it's my first stab at any program in C using libav*, so I'm tripping up in general somewhat. [08:54:13 CEST] <beandog> I'm decoding the audio just fine. I think. [08:54:41 CEST] <beandog> you can see where my limited intelligence poops out - https://gist.github.com/beandog/7f51cdd45cf7ca9c8e4fce33760dfc60#file-avbox-... [08:55:36 CEST] <rcombs> you need to loop on avcodec_receive_frame until it stops giving you frames (EAGAIN) [08:56:12 CEST] <beandog> ok [09:00:58 CEST] <beandog> just pulling out one at all throws an error, though - "error: Resource temporarily unavailable" [09:06:24 CEST] <JEEB> beandog: might be that the encoder didn't get enough data to start returning data [09:06:34 CEST] <JEEB> some encoders require larger amounts of stuff put in [09:06:40 CEST] <JEEB> like libx264 with slower presets [09:07:45 CEST] <beandog> hmm [09:07:46 CEST] <beandog> ok [09:09:31 CEST] <ubitux> beandog: av_err2str(ret) is useful [09:10:05 CEST] <beandog> ok [09:16:29 CEST] <wm4> ubitux: even then the error messages are cryptic as hell [09:18:45 CEST] <atomnuker> am I reading this right? vmaskmov solves like 99% of all opus assembly issues [09:19:33 CEST] <atomnuker> if you can conditionally store to a memory address without overwriting [09:21:18 CEST] <beandog> alright, I gotta run off to bed, thanks guys :) cookies for all [10:16:33 CEST] <BtbN> philipl, no, there's a dummy call to DecodeVideo in between [10:16:41 CEST] <BtbN> but DecodeVideo has no parameters to pass in the input buffer [10:17:25 CEST] <BtbN> calling DecodeVideo throws an error though [10:17:34 CEST] <BtbN> and MapVideo has both the input and output buffer parameters [11:19:35 CEST] <cone-514> ffmpeg 03Clément BSsch 07master:8ba1fc2a4ac2: ffprobe: discard non-selected streams [12:57:35 CEST] <BtbN> I hate Makefiles and their syntax [13:01:05 CEST] <wm4> I hate shell and its syntax [13:03:39 CEST] <cone-514> ffmpeg 03Michael Niedermayer 07master:ad2296ab3a13: avcodec/aacdec_fixed: Fix various integer overflows [13:03:40 CEST] <cone-514> ffmpeg 03Michael Niedermayer 07master:d712a5cddbfc: cmdutils_opencl: Fix read of uninitialized pointer [13:03:41 CEST] <cone-514> ffmpeg 03Michael Niedermayer 07master:36cf42252152: cmdutils_opencl: Fix read of uinitialized cl_mem [13:07:08 CEST] <BtbN> I can't get it to generate the needed file... It just doesn't care it doesn't exist, and fails at link time [13:07:33 CEST] <durandal_1707> michaelni: arent packets padded with 0? [13:07:53 CEST] <wm4> durandal_1707: the answer is "maybe" [13:08:02 CEST] <durandal_1707> how would unckecked bistream work otherwise? [13:08:23 CEST] <wm4> it usually requires only padding, not 0 padding [13:08:28 CEST] <BtbN> If I add this to the Makefile, shouldn't it trigger the whole chain when a .ptx.o is in the list of files? https://bpaste.net/show/b925a4a49011 [13:08:32 CEST] <durandal_1707> maybe unaligned and unpadded [14:30:50 CEST] <cone-514> ffmpeg 03Matthieu Bouron 07master:5d0b8b1ae307: lavc/aarch64/simple_idct: fix iOS build without gas-preprocessor [14:30:51 CEST] <cone-514> ffmpeg 03Matthieu Bouron 07master:2f43897f6579: lavc/ffjni: fix local reference leak [14:30:52 CEST] <cone-514> ffmpeg 03Matthieu Bouron 07master:1795dccde0ad: lavc/mediacodec_wrapper: fix local reference leaks [14:46:21 CEST] <Gramner> atomnuker: note that vmaskmov* has some caveats on some cpu:s that you should to be aware of before using it such as preventing load-store forwarding and messing with the memory address disambiguator causing unrelated loads to stall [14:48:47 CEST] <iive> maskmov has latency of 3000 on Ryzen ... and this is not the first AMD cpu to have issues with it. [14:49:06 CEST] <atomnuker> its not doing anything fancy, just 2 (normal, movu) loads -> stuff -> 2 vmaskmov stores [15:38:27 CEST] <jamrial> ubitux: wanna give the h264 cropping thing a look? or do we just skip it for now? [15:38:36 CEST] <jamrial> the calculated cropping offsets post merge are different, and probably wrong [15:39:50 CEST] <J_Darnley> I have sucessfully moved simple_idct to external asm... [15:40:15 CEST] <jamrial> congrats [15:41:12 CEST] <J_Darnley> I want to use some other code to do add and clamped functions. [15:41:44 CEST] <J_Darnley> Do people object adding ~800 lines to lavc/x86/idctdsp.asm? [15:42:56 CEST] <J_Darnley> Or should I copy ~100 to where I have been working? [15:52:23 CEST] <J_Darnley> I think I'll copy. I would need to duplicate a little anyway. [15:54:04 CEST] <cone-514> ffmpeg 03Michael Niedermayer 07master:d9051f8f3e60: avcodec/mimic: Fix runtime error: index 96 out of bounds for type 'const int8_t [64]' [15:54:05 CEST] <cone-514> ffmpeg 03Michael Niedermayer 07master:3a0ff78168f8: avcodec/aacdec_fixed: Fix multiple shift exponent 33 is too large for 32-bit type 'int' [15:54:06 CEST] <cone-514> ffmpeg 03Michael Niedermayer 07master:8a69f2602fea: avcodec/dvbsubdec: Check entry_id [15:54:07 CEST] <cone-514> ffmpeg 03Michael Niedermayer 07master:7ac506714661: avcodec/scpr: Check y in first line loop in decompress_i() [16:24:37 CEST] Action: kierank looking forward to see J_Darnley patch [16:30:40 CEST] Action: J_Darnley facepalms [16:30:59 CEST] <J_Darnley> Well obviously that's going toscrew you up! [16:32:38 CEST] <gnafu> Expectations ruin everything. [16:34:42 CEST] <j-b> BBB: you should give me the right to attack in your name [16:34:50 CEST] <BBB> ? [16:34:53 CEST] <J_Darnley> I should perhaps add a check to x264asm to catch those obvious errors. No CPU has 128 registers (yet). [16:34:58 CEST] <BBB> what did I do? [16:35:14 CEST] <j-b> BBB: gpl violations [16:35:20 CEST] <BBB> uh [16:35:22 CEST] <BBB> dunno [16:35:37 CEST] <j-b> Synology violates since 2 years! [16:35:44 CEST] <BBB> so many people violate [16:35:46 CEST] <BBB> nobody cares [16:35:46 CEST] <j-b> it's not like a small thing [16:35:48 CEST] <RiCON> 100 whole apps [16:35:49 CEST] <BBB> I tried for a little while [16:36:00 CEST] <BBB> and its just too hard and too slow [16:36:09 CEST] <BBB> and most violators are not in appropriate jurisdictions [16:36:17 CEST] <BBB> and if they are, all you get is $1000 or so [16:36:19 CEST] <BBB> whats the point [16:36:28 CEST] <j-b> or way more [16:36:36 CEST] <j-b> and forbid them from distributing [16:37:45 CEST] <BBB> we need a more sustainable system than what we have now [16:37:53 CEST] <BBB> having one developer do it makes no sense [16:38:04 CEST] <BBB> maybe set up a collab with a law school and have their students do it as a summer project [16:38:05 CEST] <BBB> every year [16:38:19 CEST] <BBB> summer of code style [16:38:39 CEST] <Gramner> summer of lawsuits [16:38:55 CEST] <jamrial> what exactly do they violate gpl for? what gpl code could mobile apps need? doubt it's external library encoders [16:40:02 CEST] <Gramner> maybe we should pitch practicing handling gpl violations as course material for law school [16:40:16 CEST] <BBB> jamrial: who knows [16:40:31 CEST] <BBB> jamrial: dont forget ios doesnt allow shared libs [16:40:37 CEST] <BBB> jamrial: so full lgpl compliance is hard [16:42:08 CEST] <j-b> that's totally untrue [16:42:15 CEST] <j-b> iOS support shared libs since iOS8 [16:42:23 CEST] <j-b> 3 major versions ago [16:47:09 CEST] <atomnuker> what's the shortest way to convert decimal to 1's e.g. 1 -> 0x1, 2 -> 0x3, 3 - 0x7, 4 - 0xf, etc? [16:47:32 CEST] <BtbN> Why the hell does make delete my intermediate build files, and then isn't smart enough to figure out the build is up to date when re-running it? [16:48:15 CEST] <atomnuker> ugh, I'll just use a lookup table, I only need up to 4 [16:48:50 CEST] <BtbN> https://bpaste.net/show/f1d4c223a851 like, what? Why? [16:49:16 CEST] <nevcairiel> atomnuker: (1 >> x) - 1? [16:49:55 CEST] <jamrial> << [16:50:00 CEST] <nevcairiel> right [16:50:01 CEST] <nevcairiel> my bad [16:50:03 CEST] <wm4> j-b: there's still the question whether the tivo clause allows gpl/lgpl at all [16:50:13 CEST] <wm4> or was that only v3 [16:50:29 CEST] <j-b> wm4: only GPLv3 [16:50:48 CEST] <j-b> GPLv2/LGPLv2.1 is ok with tivo [16:50:51 CEST] <j-b> LGPLv3 is unclear [16:51:01 CEST] <ubitux> jamrial: not much more to say than what i said last time& [16:52:04 CEST] <wm4> in any case even without shared libs you can apparently comply to lgpl [16:52:16 CEST] <wm4> by proving .o files [16:52:33 CEST] <wm4> though I wonder why the FSF chose such clunky requirements [16:52:59 CEST] <wm4> in practice this is not going to help a single user [16:53:09 CEST] <j-b> because they are lawyers [16:53:19 CEST] <j-b> wm4: a long time ago, I wrote a GPL-short license [16:53:23 CEST] <j-b> same spirit as GPL [16:53:27 CEST] <j-b> but in a few sentences [16:53:43 CEST] <wm4> but? [16:55:09 CEST] <wm4> I think plenty of people would like a LGPL-style smaller licemse [16:55:12 CEST] <wm4> license even [16:56:01 CEST] <j-b> wm4: but, I had 2 guys from FSF that broke my balls [16:56:05 CEST] <j-b> and I dropped the project [16:57:16 CEST] <wm4> lol did they threaten to sue you [16:57:19 CEST] <j-b> no [16:57:31 CEST] <j-b> they started to explain how it will make the life of everyone more complex [16:57:42 CEST] <j-b> because of compatibilities between GPL-light and GPL [16:58:10 CEST] <atomnuker> nevcairiel: tnx, that's the 1 way of shifting I didn't consider [16:58:23 CEST] <wm4> oh yeah, that's a "nice" property of GPL [16:58:29 CEST] <durandal_1707> name of project is? [17:11:47 CEST] <jamrial> ubitux: the problem seems to be the left cropping value being reduced to keep alignment when -flags unaligned is not set [17:11:50 CEST] <jamrial> h264/hevc/theora do it one way, the new decode.c code another way [17:12:30 CEST] <jamrial> i guess i could try to make decode.c behave the same, but wonder why it was changed in the first place [17:13:01 CEST] <wm4> does this affect actual cropping, or the exported AVFrame cropping values? [17:15:51 CEST] <atomnuker> wait, so I cannot shift a grp using another grp to specify shift amount? [17:16:16 CEST] <atomnuker> (yet that's doable in SIMD?) [17:16:29 CEST] <BBB> of course you can [17:16:33 CEST] <BBB> but you can only shift with ecx [17:16:34 CEST] <BBB> (cl) [17:17:46 CEST] <BBB> atomnuker: I dont know why that limitation exists, but only ecx can shift (though any reg can be shifted) [17:20:41 CEST] <jamrial> wm4: actual cropping [17:28:30 CEST] <BBB> are you guys getting all these privmsgs from a user called BotRoomNN"? [17:28:34 CEST] <BBB> how do I ignore that? [17:28:51 CEST] <J_Darnley> Not me and I don't know. [17:30:15 CEST] <Gramner> atomnuker/BBB: with bmi2 there's sensible 3-arg variable shift instructions [17:30:39 CEST] <Gramner> shrx/shlx/sarx [17:31:07 CEST] <Gramner> which are also faster than using cl on intel cpus because reasons [17:32:53 CEST] <Gramner> 1/0.5 vs 2/2 on skylake [17:36:18 CEST] <BBB> intel has so many reasons for so much crap behaviour [17:36:25 CEST] <BBB> I never quite know what to think of it [17:36:30 CEST] <BBB> I guess it works so WhyCare [17:37:33 CEST] <Gramner> most of the weird performance issues are due to legacy x86 crap. like partially affecting flags, or behavior being different when src==0 and things like that [17:38:48 CEST] <wm4> why didn't Intel come up with a new instruction set mode yet? [17:38:59 CEST] <Gramner> they did. it's called itanium [17:39:10 CEST] <Gramner> we all know how well that worked out [17:39:19 CEST] <wm4> itanium was "revolutionary" [17:39:28 CEST] <wm4> I mean something more like ARM did with Thumb [17:39:43 CEST] <Gramner> because customers care about backwards compatibility [17:39:54 CEST] <Gramner> so they still need to have all legacy crap [17:40:11 CEST] <wm4> it can be... they can do the same like they signal the bitness of code [17:40:20 CEST] <wm4> 15 vs. 32 vs. 64 bit code [17:40:27 CEST] <wm4> *16 [17:40:31 CEST] <J_Darnley> 15-bit code? Nice [17:41:00 CEST] <Gramner> modern microprocessors are insanely complex to validate as it is, not sure they want to go down that rabit hole [17:41:07 CEST] <BBB> they couldve fixed it with x86-64 [17:41:11 CEST] <Gramner> I'm guessing they will drop 16-bit at some point though [17:41:54 CEST] <Gramner> yes. they could've, and should've, fixed (read: dropped) a lot of stuff [17:41:56 CEST] <atomnuker> I dislike how I have to use cmov to clamp an integer, a separate clamp instruction would've been nice [17:42:05 CEST] <Gramner> hindsight is 20/20 [17:42:51 CEST] <kierank> atomnuker: do it in simd [17:43:00 CEST] <wm4> 64 bit mode was AMD, which focused on max. compatibility to existing toolchains or something [17:43:42 CEST] <wm4> Gramner: well the idea is that they would gradually switch to slower emulation for the "old" instruction set [17:44:39 CEST] <Gramner> that's already happening with mmx and x87 [17:45:06 CEST] <atomnuker> kierank: pretty much what I do, I splat an integer and multiply each word to get the bit in the correct place [17:45:16 CEST] <Gramner> you can gain performance by converting mmx simd to sse2 that only uses the lower half on skylake [17:45:31 CEST] <Gramner> depends on which instructions are used [17:45:32 CEST] <kierank> J_Darnley: ^ [17:45:41 CEST] Action: wm4 wish swscale would remove this funny self-modifying mmx code for a broken scaler [17:45:53 CEST] <wm4> can't make that up [17:46:42 CEST] <Gramner> self-modifying SIMD sounds scary [17:47:03 CEST] <kierank> wm4: you know perfectly well that weird shit isn't going to go away [17:47:04 CEST] <kierank> FAST [17:47:05 CEST] <kierank> SPEED! [17:48:16 CEST] <wm4> :( [17:48:48 CEST] <kierank> at least with mpeg2 mmx I can ask J_Darnley to get rid of it [17:48:54 CEST] <BBB> Gramner: its there [17:48:57 CEST] <Gramner> self-modifying code tends to be slow though since it messes a lot with internal cpu behavior [17:48:59 CEST] <BBB> Gramner: its crazy [17:49:11 CEST] <BBB> Gramner: and its crazy fast for mmx code, yes [17:52:23 CEST] <atomnuker> self-modifying code sounds so radical though [17:53:14 CEST] <wm4> at least it seemed to stop upsetting selinux and actively bothering users [17:57:08 CEST] <iive> wm4: itanium was slow. nowdays even gpu's move away from vliw [18:01:09 CEST] <iive> the "self modifying code" is modified once before execution and doesn't change itself after that. so it is more like dynamic compilation of code [18:01:19 CEST] <Gramner> that swscale code isn't self-modifying though. it's runtime-generated and not very scary. I'm disappointed! [18:02:07 CEST] <iive> :) [18:02:54 CEST] <atomnuker> Gramner: if itanium processors weren't a failure would the instruction set be okay to work with? [18:04:06 CEST] <Gramner> the itanium instruction set was designed around smart compilers. e.g. the compiler would figure out all the things that could be done in parallell so the cpu wouldn't have to [18:04:49 CEST] <Gramner> turns out writing good compilers is hard, and out-of-order execution in hardware is actually really good [18:07:25 CEST] <Gramner> writing vliw asm by hand seems kind of annoying [18:08:59 CEST] <atomnuker> the arm camp still seems to believe in smart compilers [18:11:21 CEST] <wm4> iive: well I didn't say it should be vliw [18:11:40 CEST] <wm4> Itanium was essentially a failed experiment, but they didn't play it save in the first place [18:12:21 CEST] <wm4> the arm thumn instruction set on the other hand is a "safe" optimization that brought obvious benefits [18:12:32 CEST] <wm4> *thumb [18:12:37 CEST] <wm4> no radical new concepts [18:14:21 CEST] <Gramner> the current x86 approach is basically "SIMD ALL THE THINGS" due to dennard scaling failing on us [18:16:56 CEST] <wm4> what's dennard scaling? [18:17:09 CEST] <Gramner> gathers, scatters and conflict detection in avx-512 feels very much designed for compilers, because it's rare to need such things in handwritten SIMD and inferring inter-dependencies between data can be very hard or impossible for a compiler to do, so just let the hardware deal with it [18:17:16 CEST] <Gramner> https://en.wikipedia.org/wiki/Dennard_scaling [18:18:05 CEST] <Gramner> it's why we don't have 30GHz cpus [18:21:16 CEST] <nevcairiel> i wonder if you could make single cpu cores somehow bigger for more performance, instead of just scaling up cores to use the space [18:21:24 CEST] <nevcairiel> (other then introducing new simd) [18:21:49 CEST] <thardin> new paradigms may be needed. such as computing at optical frequencies [18:22:55 CEST] <Gramner> you can add more cache and increase out-of-order execution windows, in-flight load/store buffers etc (which is what cpu designers tend do every new arch nowadays) but all of this has diminishing returns [18:23:13 CEST] <Gramner> this is a physics issue, not a design issue really [18:23:42 CEST] <nevcairiel> so essentially, x86 isnt going to get much faster [18:24:28 CEST] <J_Darnley> Finally! People will stop writing slower software [18:26:06 CEST] <atomnuker> not even gallium arsenide would help nowadays, it would actually make things worse [18:26:28 CEST] <Gramner> we'll get more cores, wider simd, more execution engines and slightly better IPC due to general arch improvements, but probably nothing major until a completely new material with better physical properties that is viable to create transistors out of shows up [18:26:47 CEST] <J_Darnley> GRAPHENE! [18:26:55 CEST] <Gramner> yes, graphene is one contender [18:49:17 CEST] <jamrial> ubitux, michaelni: libav is also affected by this change in cropping behavior, so i'll just skip these commits for now [18:59:52 CEST] <BtbN> I think I won against the Makefiles [18:59:57 CEST] <BtbN> I hate Makefiles [19:04:28 CEST] <J_Darnley> Dinner then patch squashing time. [19:05:23 CEST] <cone-514> ffmpeg 03Anton Khirnov 07master:a02ae1c6837a: hevcdec: export cropping information instead of handling it internally [19:05:24 CEST] <cone-514> ffmpeg 03Anton Khirnov 07master:4fded0480f20: h264dec: be more explicit in handling container cropping [19:05:25 CEST] <cone-514> ffmpeg 03Anton Khirnov 07master:c3e84820d67c: h264dec: export cropping information instead of handling it internally [19:05:26 CEST] <cone-514> ffmpeg 03Anton Khirnov 07master:1202b712690c: theora: export cropping information instead of handling it internally [19:05:27 CEST] <cone-514> ffmpeg 03James Almer 07master:fc63d5ceb357: Merge commit '1202b712690c14f0efb06e4ad8b06c5b3df6822a' [19:05:28 CEST] <cone-514> ffmpeg 03James Almer 07master:602ac487205e: doc/libav-merge: mention the skipped AVFrame crop fields usage commits [19:27:17 CEST] <atomnuker> I like how in newer nasm versions you don't have to use that obscure debug option to resolve errors in macros [19:27:28 CEST] <atomnuker> who thought that was a good idea [19:27:50 CEST] <iive> what is the obscure debug option? [19:28:19 CEST] <atomnuker> I can't remember, something you appended on make, its in the docs [19:28:41 CEST] <atomnuker> DBG=1 [19:39:30 CEST] <ubitux> jamrial: even git/master ? [19:39:59 CEST] <jamrial> ubitux: libav? yes [19:40:42 CEST] <jamrial> i checked to see if it was fixed/changed in a following commit so i'd just cherry pick it as part of the merge, but no [19:44:23 CEST] <ubitux> ok ok [19:54:23 CEST] <jamrial> and here i was happy i got rid of an item from the libav-merge list, only to end up adding another :p [20:08:42 CEST] <cone-514> ffmpeg 03Michael Niedermayer 07master:e717fa1f0a66: avcodec/cllc: Factor VLC_BITS/DEPTH out, do not use repeated literal numbers [20:08:43 CEST] <cone-514> ffmpeg 03Michael Niedermayer 07master:2bfd0a97587d: avcodec/cllc: Check num_bits [20:08:44 CEST] <cone-514> ffmpeg 03Michael Niedermayer 07master:15e892aad12b: avcodec/msmpeg4dec: Check for cbpy VLC errors [20:21:21 CEST] <ubitux> jamrial: yeah :( [20:22:11 CEST] <ubitux> jamrial: but it's better to have to deal with this list on a daily basis than the overall merge count we currently fight [20:22:21 CEST] <ubitux> so its time will come [20:27:44 CEST] <ubitux> seems our qsvenc is still quite a bit different [22:37:12 CEST] <SviMik> can anybody say why ffmpeg sometimes puts chromaticities and gamma info into png file? what is it intended for? http://svimik.com/ffmpegpngformats1.png [22:37:18 CEST] <SviMik> I have noticed that colors in png are screwed when in does so. Is there a way to disable it? [22:39:16 CEST] <nevcairiel> it writes those if the color information is set on the encoder [22:39:22 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/pngenc.c#L293 [22:39:56 CEST] <BtbN> If it has the information, it will write them [22:52:03 CEST] <iive> atomnuker: found it, it compiles the .asm with -e option that basically only does preprocessor and saves the result in *.dbg.asm file, that is compiled/assembled on a second run. [00:00:00 CEST] --- Fri May 12 2017