00:20:28 -!- ais523 has quit. 00:20:38 -!- ais523 has joined. 00:24:21 -!- Phantom_Hoover has quit (Remote host closed the connection). 00:31:05 -!- ais523 has quit (Quit: antilunch). 00:33:30 -!- GeekDude has joined. 00:51:52 -!- ^v has quit (Ping timeout: 240 seconds). 01:04:36 -!- ais523 has joined. 01:18:24 -!- ^v has joined. 01:23:22 -!- ^v has quit (Ping timeout: 240 seconds). 01:27:39 -!- ^v has joined. 01:33:45 -!- oerjan has quit (Quit: leaving). 02:03:56 -!- GeekDude has quit (Quit: {{{}}{{{}}{{}}}{{}}} (www.adiirc.com)). 02:05:28 -!- GeekDude has joined. 02:29:08 -!- madbr has joined. 02:44:12 -!- TodPunk has quit (Ping timeout: 260 seconds). 02:46:53 -!- TodPunk has joined. 02:48:22 -!- Patashu has quit (Remote host closed the connection). 02:48:42 -!- Patashu has joined. 02:58:22 -!- GeekDude has quit (Quit: {{{}}{{{}}{{}}}{{}}} (www.adiirc.com)). 03:06:47 -!- Bicyclidine has joined. 03:15:26 -!- shikhin has joined. 03:18:28 -!- shikhout has quit (Ping timeout: 244 seconds). 03:23:11 I get a message "warning: this decimal constant is unsigned only in ISO C90". What should I do about that? The relevant line of code is: if(x&1) mt[ind]^=2567483615L; 03:23:33 use UL suffix instead, I think 03:23:44 or was it LU 03:23:50 I think either works, but I always use UL 03:24:17 `! long unsigned x = 4LU; printf("%lu\n", x); 03:24:17 /hackenv/bin/!: 4: exec: ibin/long: not found 03:24:21 `! c long unsigned x = 4LU; printf("%lu\n", x); 03:24:22 Does not compile. 03:24:23 hmm 03:24:29 `! c long unsigned x = 4UL; printf("%lu\n", x); 03:24:30 Does not compile. 03:24:55 hmm, there are too many things that could have gone wrong there 03:25:05 `! c printf("Hello, world!\n"); 03:25:06 Does not compile. 03:25:10 welp 03:25:21 `! c extern int puts(const char *); puts("Hello, world!"); 03:25:22 Hello, world! 03:25:24 `` ls bin | grep c 03:25:25 botsnack \ buttsnack \ calc \ catcat \ cats \ cc \ cdecl \ c++decl \ chroot \ coins \ complain \ complaints \ danddreclist \ echo \ echo \ emoclew \ fsck \ gccrun \ icode \ lowercase \ luac \ luarocks \ luarocks-admin \ macro \ marco \ morse-decode \ multicode \ ozcome \ psocmd \ qc \ quachaf \ r13elcome \ rec \ relcome \ ReLcOmE \ runc \ runcp 03:25:26 missing stdio.h 03:25:33 The variable is the same size; I am not sure why it should display a warning in such a case. 03:25:36 `cc puts("q") 03:25:36 /tmp/a.c:1:6: error: expected declaration specifiers or ‘...’ before string constant 03:25:39 `cc puts("q"); 03:25:39 /tmp/a.c:1:6: error: expected declaration specifiers or ‘...’ before string constant 03:25:40 which is awkward, because I can't include it without a newline 03:25:43 `cc int main() { puts("q"); } 03:25:44 q 03:25:53 ais523: I think it interprets \n 03:26:01 `! c printf("q\\n"); 03:26:02 q 03:26:17 you misdiagnosed the problem 03:26:23 aha 03:26:28 `! c long unsigned x = 4UL; printf("%lu\\n", x); 03:26:29 4 03:26:32 there we go 03:26:37 `! c long unsigned x = 4LU; printf("%lu\\n", x); 03:26:38 4 03:26:41 LU everywhere 03:27:19 `! c unsigned long x = 4UUL; printf("%lu\\n", x); 03:27:20 Does not compile. 03:27:43 OK, I put UL instead of just L and now it isn't warning, but like I said it shouldn't matter in this case if it is signed or not. 03:28:08 (Since, the type of the variable is long, too) 03:28:49 I think the problem is that it's too big for the signed version 03:28:57 because the C standard only guarantees literals of a certain size or whatever 03:29:29 if you have a constant between the range of int and unsigned int, then it depends on the standards version whether its type is unsigned or long 03:29:36 which can definitely matter if you use it in a comparison, or the like 03:29:41 `rm bin/quachaf 03:29:42 No output. 03:30:04 this is why gcc is complaining, it's telling you to specify the type in order to avoid confusion later 03:30:27 unsigned or long long, in this case, because you presumably have sizeof (int) == sizeof (long) 03:31:45 But as you can see, it isn't a comparison. 03:32:36 ais523: why presumably? 03:33:16 elliott_: otherwise "L" wouldn't be ambiguous, it'd be unambiguously long 03:33:35 there's a very small chance that int is only 16 bits and long is 32 bits; higher than usual because this is zzo38 we're talking about 03:33:56 Don't you need two "L"s for "long long"? 03:34:08 zzo38: yes, and that would also be unambiguous 03:34:30 basically gcc's complaining that the constant should either be 2567483615UL or 2567483615LL 03:34:37 and which it is depends on whether you're using c89 or c99 03:35:17 O, that's what it means. 03:39:29 -!- tlvb has quit (Ping timeout: 258 seconds). 03:42:47 ais523 : isn't sizeof int 4 and sizeof long long 8? (and then long is 4 bytes on msvc and 8 on gcc) 03:43:41 madbr: not always, although those are very common nowadays 03:43:50 I grew up on compilers where sizeof (int) was 2 03:43:59 that's 20 years ago 03:44:01 also, note that you need the parens when using sizeof on types 03:44:29 I think it's sparc that has 64bit ints? 03:44:40 it's one of the 64bit RISCs 03:45:00 ABI is an OS thing as well as an architecture thing 03:45:06 irl it doesn't really make sense because you rarely need ints that large 03:45:17 for instance long is 32-bits on x86-64 windows and 64-bits on x86-64 linux 03:45:24 yes 03:45:30 so you should never use long 03:45:38 unless you like things breaking 03:46:51 madbr: I use "long" as a sort of ghetto uint_least32_t 03:46:51 well, the same applies to int, really. 03:46:57 platform-specific integer sizes aren't a great idea. 03:47:01 ais523 : why not int? 03:47:08 because int can be 16 bits 03:47:12 dude 03:47:32 if you compile on a platform with 16bit ints probably everything will break 03:47:44 I agree, your code probably doesn't work on embedded platforms 03:47:45 array with more than 16k values? break 03:47:48 madbr: many of my programs needed changes to work with 32bit ints 03:47:55 I think ais523's code is significantly more likely to 03:48:05 basically because the Windows API had a number of breaking changes in terms of source code between 3.1 and 95 03:48:07 madbr: um, arrays are indexed by size_t, not int 03:48:19 and I was inexperienced enough not to be aware of portability issues 03:48:25 Windows upgrades soon trained me differently, though 03:48:41 Windows may be good at running old binaries, but it's rather less good at compiling old source 03:48:45 elliott_ : that's really an embedded platform thing tbh 03:48:57 what? no. int is 32 bits on x86-64 linux and you can have arrays bigger than 2 gigabytes 03:49:10 that's why you use size_t 03:49:15 sed -i '/%lu/%zu/' * # magically, errors disappear 03:49:19 (also, there were a number of issues, e.g. the standard way to play a MIDI file on Windows 98 freezes your program for like 30 seconds the first time you try it on Windows XP) 03:49:26 if you have a 2gb array there almost is certainly somethinbg else wrong with your code 03:49:27 (or was it 95 to 98?) 03:49:30 warnings, whatev, everything's catastrophic 03:50:22 madbr: a minute ago you were saying size_t is an embedded platform thing? 03:50:38 no what I'm saying is that 16bit int is an embedded platform thing 03:50:47 are you just making up context-free rebuttals that sound snappy rather than ever admitting you're wrong 03:51:31 what I'm saying is that yes 16bit platforms are a thing, but irl it's very unlikely that general c++ code will even run on those 03:51:43 madbr: I wrote C++ on 16-bit platforms for years 03:51:53 ais523 : on x86? 03:51:58 yes 03:52:05 yes 03:52:12 who said anything about c++? 03:52:12 16bit x86 WAS a thing 03:52:16 but it's long dead 03:52:31 elliott_ : once again, embedded platform 03:52:39 "long" = "approximately when Vista was released" 03:52:39 what. 03:52:43 that's not that long ago, people still use XP 03:52:48 I was talking about C, I'm pretty sure ais523 was too 03:52:54 what do embedded platforms have to do with it? 03:52:56 16bit has been dead since win32 03:53:01 that's windows95 03:53:11 elliott_: I "learned" C++ before C 03:53:16 like, sure you can run 16bit apps on win95 03:53:30 but there was no reason to make new ones from then on 03:53:57 I still write 16-bit DOS programs sometimes though 03:54:15 i "learned" c++ before c also, it's pretty hilariosu 03:54:20 ah... all the dos programs I've written were 32 bit 03:54:30 do you think nobody uses c on embedded platforms because they all use c++ or something, or... 03:54:34 madbr: there was plenty of reason, and that's that the 32-bit development toolchain I had didn't actually work 03:54:42 like, it worked sometimes 03:54:52 but it would frequently fail in bizarre circumstances 03:54:56 elliott_ : no what I mean is, if you're writing embedded platform code, yes then 16bit C totally makes sense 03:54:59 16-bit was a lot more stable back then 03:55:04 but it's a marginal case 03:55:13 you have to realise that 32-bit code was new and relatively untested, so most people used 16-bit 03:55:24 also I got to control the PC speaker, which was a Windows 1 feature that was deprecated 03:55:35 but trying to play music via MIDI, the next-simplest method, was still way more complex 03:55:38 what, the internal beeper thing? 03:55:43 for other, non embedded applications, there's no way 16 bit even exists anymore 03:55:44 Bicyclidine: yes 03:56:16 hmm, I'm not sure if I could still run my old programs 03:56:22 at least one version of DNA Maze was Win16 API 03:56:34 dna? 03:56:51 sounds like this is a good time to talk at length about methylation 03:57:00 it's a computer game that I used to work on, ages ago 03:57:14 so except for embedded platforms, you're now 100% guaranteed that int's will be at least 32 bits no matter what 03:57:21 it was originally for DOS, then I reworked the level select leading to a new major version 03:57:37 madbr: is this desigend to troll people into finding counterexamples? because it's almost working on me :) 03:57:37 then it got ported to various other systems, such as Win16 and some Linux (I think SDL1) 03:57:53 (I suspect you would just define "embedded platform" as "platform with 16-bit int", though, which isn't really entirely unreasonable.) 03:57:56 do you count games consoles as embedded platforms? 03:58:23 elliott_: a nice working definition for "embedded platform" is "platform for which dynamic allocation would be an utterly crazy idea" 03:58:27 elliott_ : ok what 16bit platform that isn't embedded could you possibly want to write for? 03:58:56 that's not a bad definition and now i want to write malloc on my pic32 03:59:06 madbr: you're asking that in #esoteric? :p 03:59:08 the traditional examples were real mode DOS and win16 but those are long gone 03:59:09 probably good practice, honestly 03:59:35 For such "embedded platform" (whatever youre definition will be) I don't program them in C anyways. 03:59:36 I guess there's always real mode boot loaders 03:59:51 madbr: http://esolangs.org/wiki/BytePusher would have 24 bit int, maybe. 04:00:00 for 8 bit platforms... you're going to write in assembly 04:00:02 madbr: Yes, although I suppose you could write them in assembly language instead of in C. 04:00:06 uh, I guess that's maybe not allowed 04:00:07 but it should be! 04:00:27 what, does it have to be 2^n * CHAR_BIT? suxk 04:00:32 I suppose FreeDOS is also real mode, although it can run programs in protected mode too 04:00:34 elliott_ : does it have a C compiler? 04:01:03 madbr: it could 04:01:05 don't tempt me to write one 04:01:06 does FreeDOS ship its own DPMI extender? or do you have to provide one? 04:01:37 elliott_ : until that happens, you're guarenteed 32 bit ints 04:01:46 -_- 04:01:53 you're really tempting me 04:02:01 there's also the question of platforms with 64 bit ints 04:02:21 let's compromise on 48 04:02:25 ais523: I don't know, although perhaps it ought to include such a thing. 04:02:39 zzo38: I know that for the NetHack TAS, I had to include a DPMI extender 04:02:54 but I can't remember whether that's because FreeDOS doesn't have one, or because it didn't emulate correctly in JPC-RR 04:03:05 and the answer is that we've stopped making those... basically they figured that 64bits were too large for most uses 04:03:43 madbr: supercomputers often have 64-bit ints 04:03:47 some DSPs have 32-bit chars 04:04:07 and they're basically making 64bit architectures to mix up 32bit data with 64bit pointers (arm64 has a whole bunch of instructions dedicated to mixes and conversions etc) 04:04:43 There are also some VMs having bytes longer than 8-bits (such as 16-bits or 32-bits) 04:04:51 ais523 : you mean like word addressed DSPs? 04:04:57 madbr: yes 04:05:00 right 04:05:25 though afaik it's rare to run general purpose code on these 04:05:37 madbr: what do you mean by "general purpose code", though? 04:05:49 an FFT is pretty general-purpose, and DSTs run those all the time 04:06:05 really I think we should just have stdint.h and remove all of C's integer types. 04:06:33 and maybe give the "least" versions shorter names, but maybe not since platform-specific overflow bugs are uuurgh. 04:06:36 Or to define them in the other way around 04:06:50 ais523 : code that isn't purpose-written for that particular use? and that does all sorts of stdlib calls, std::, are designed for modern paged memory protected stuff, C++... 04:07:09 madbr: every program is purpose-written for something or other, unless it's a general-use library 04:07:12 like, I'm pretty sure none of these DSPs have an MMU 04:07:16 and many general-use libraries hardly touch stdlib 04:07:23 consequently something like std::map would probably leak 04:08:22 dude, you're the one bringing C++ into this. 04:08:48 like, the sound processing code I'm writing these days, runs on x86 of course, and I know very well that it has to be easy to run on ARM 04:09:00 because that port has very high chances of happening 04:09:42 and that I should perhaps not count on byte order because a port to POWER could still happen maybe (nintendo wii u etc) 04:10:52 but if it has to be ported to a word addressed DSP, then it's going to have all sorts of special limitations like no threading, no mmu or paging, very small ram, no fpu, etc... 04:11:15 and consequently it's going to have to be specially written more or less no matter what 04:11:33 so there's little point in keeping in mind that sort of platform when writing code 04:11:43 look, there's a world of programming outside your very insular conception of it (which you call "general-purpose", I guess), and C is designed to cover a hell of a lot of that world. that's what it comes down to 04:12:28 the code I write is C++, not C 04:12:49 madbr: sound-processing code is something that people are quite likely to want to run on a DSP, fwiw 04:13:14 ais523 : it can happen yes 04:13:24 madbr: yes, and as I've been trying to point out the conversation was about C before you joined in and continued to be about C thereafter until you brought C++ into it 04:13:27 but IRL it involves making a hardware product, basically 04:13:52 there's no computer, cell phone or console platform where you can even write for the DSP 04:14:00 when there is one at all 04:14:03 madbr: ? 04:14:11 how do you think people do DSP development? 04:14:28 it's not my line of work tbh 04:14:34 so I'm not too familiar 04:14:59 madbr: well, what you do is, you use an IDE, and use it to compile your files into executables, just like with any other IDE 04:15:05 right 04:15:15 but then you have to be hooked into a devkit 04:15:19 or something like that 04:15:19 then you tell it to copy the executables onto the DSP, which is connected to the computer via a special programming device 04:15:21 then it runs them 04:15:32 yes special programming device 04:15:36 outboard gear 04:15:44 that's what I mean when I say "hardware product" 04:15:57 madbr: well given that the DSP isn't powerful enough to run an IDE itself… 04:16:32 like, if you're programming a DSP, you're obviously not making a product that is a win32 program 04:16:43 madbr: this is no different from, say, programming a cellphone 04:17:01 and more to the point, nothing prevents you from simply copying in code from elsewhere 04:17:27 true but it's still a "special" platform 04:18:45 like, does it even make sense to run C++ on that kind of DSP? 04:19:05 ais523: not sure if you've noticed, but nothing you can say will get any kind of acknowledgement that you're in the right here 04:19:25 meh 04:19:37 elliott_: I know, but I'm kind-of stressed in RL and taking on a pointless argument's a good way to relax 04:19:51 ok fine you COULD want to port any piece of C/C++ code to word addressed architectures 04:20:17 or other similar architectures 04:20:23 and in that special case your assumption that int is 32bits will break and you will cry 04:20:32 how about an argument on the topic of pointless topology 04:21:31 isn't it topological spaces w/o points 04:21:31 imagine if you just used a type that wasn't int if you knew you needed 32 bits of range 04:21:33 madbr: and if you'd just used int32_t or int_least32_t or long, everything would have been fine 04:21:35 like, for instance, int32_t 04:21:36 or something 04:22:02 well, at least it's a thing where you don't talk about the points? 04:22:05 ais523 : in that case I'd just search and replace "int" for "int32_t" 04:22:06 a couple of days ago, I needed a type whose semantics was "a bitfield of 32 bits, addressed arithmetically" 04:22:09 I used unsigned long 04:22:11 madbr: haha seriously? 04:22:18 have you any idea how much that would break? 04:22:21 as in you just talk about the lattice of open sets or something 04:22:25 ais523 : depends how large it is 04:22:31 madbr: a hint: pointers exist 04:22:56 ais523 : if the code is small then obviously I'll check each use 04:23:06 -!- Sprocklem has joined. 04:23:06 imagine if you wrote code that wasn't broken, instead of trying to patch it up after the fact 04:23:12 wait, you'd be /more/ likely to s/int/int32_t/g if the codebase was large? 04:23:32 if the codebase is large then it's more of a problem 04:23:55 but then if the codebase is large I think it's very unlikely to be something you'd run on a DSP 04:24:27 it's not my area of expertise but AFAIK normally that sort of platform is a general purpose CPU + a DSP 04:24:44 and most of the code runs on the CPU except the number crunching stuff of course 04:25:13 -!- Sgeo_ has quit (Read error: Connection reset by peer). 04:25:46 madbr: I've used a DSP once; in that situation, it was connected on the analog side to a custom-built RF→IF mixer and antenna (not superheterodyne, we used software for that); and on the digital side to a CPU running ucLinux (wasn't a Raspberry Pi, but probably would have been if they had been invented at the time, it was the same sort of thing) 04:26:10 raspberry pis are big enough to just run normal linux 04:26:37 -!- Sgeo has joined. 04:26:41 ais523 : right. how much code ran on the DSP itself, as opposed to the rest of the system? (presumably an ARM?) 04:26:47 elliott_: right, this system was also only just big enough 04:26:56 we had to uninstall ALSA to fit Python on there 04:27:15 (we were looking for packages that were part of the stock install but that we didn't need) 04:28:01 madbr: the DSP itself did AM and FM demodulation; the rest of the system did Morse Code unencoding and had a rudimentary UI 04:28:26 although most of that system was soft realtime code to communicate with the DSP fast enough 04:29:13 right, so most of that system ran on a cpu where int was 32bits and everything was byte addressed? :D 04:29:47 depends on what you mean by "most" 04:30:10 most of that system was the RF→IF mixer and antenna 04:30:18 hmm 04:30:22 it was a 10-person team, only 2 of us worked on the CPU portion of it 04:30:26 and only part-time 04:31:06 ais523: huh, python will run on uclinux? 04:31:09 admittedly, we got two people building the power supply because they were dangerously incompetent, and that was a small enough part of the project that we hoped we'd be able to fix whatever they came up with within a few minutes 04:31:16 elliott_: apparently so 04:31:26 ais523: I guess they care about portability to embedded systems, like some kind of weird C programmers 04:31:31 I mean, malloc() works just fine on uclinux, the most common thing you can't do is mmap() 04:31:38 and mmap() is relatively obscure 04:34:51 what was the DSP code written in? 04:34:58 C? assembly? 04:35:16 C, except I kept looking at the generated asm, then tweaking the C until I got the output I wanted, because the compiler wasn't very good 04:35:24 I wrote an interrupt handler in asm, but that was just 8 bytes long 04:35:35 ah, ok 04:36:06 err, 8 words 04:36:15 (of machine code; it was longer in asm, obviously) 04:36:41 that DSP had a different word size for code than for data, and IIRC, neither was 8 04:36:57 yeah that was what I was going to ask 04:37:09 if it had separate memory buses for code and data basically 04:38:20 if you run my code over that kind of thing, it will break horribly, yes 04:38:25 it might have had 14-bit words for code, but that might have been a different system 04:38:28 I don't expect to see that day 04:38:47 also, it takes a lot of effort to write C or C++ code that breaks when code and data address spaces are separate 04:38:56 you can't cast between void * and void (*)() for a reason 04:39:11 is it even possible? 04:39:16 without going outside the standard 04:40:03 elliott_: there's no method that's guaranteed to work 04:40:15 however, if you just write the cast, it's likely to work on all the compilers that are capable of supporting it 04:40:16 I think a lot of "general purpose architecture" code would break if you couldn't cast from void * to void (*)() 04:40:25 madbr: I don't 04:40:25 ais523: you can do lots of things relying on UB :p 04:40:46 elliott_: obviously it isn't possible without going outside the standard otherwise, because there are some pieces of hardware on which it's literally impossible 04:40:47 ais523 : hmm 04:40:51 oh oh hey i have a question about code and data address spaces 04:40:58 I think POSIX guarantees (void *) and (void (*)()) are intercastable 04:41:00 are there harvard architecture machines where you can't jump to data memory 04:41:12 because i assumed that wouldn't work, but apparently it does for the particular microcontrollers class uses 04:41:38 Bicyclidine : does it have a separate memory bus for code? 04:41:56 i think it goes through the mmu 04:42:08 which... now i'm wondering how that works bus-wise, hm 04:42:08 Bicyclidine: jumping to data wouldn't work on most of the microcontrollers I've used 04:42:23 it also doesn't even work on most modern computers with modern operating systems 04:42:31 I didn't knew there were microcontrollers with MMUs 04:42:33 at least, not unless you specifically tell the MMU that that's what you're planning to do 04:42:35 maybe i should actually try it instead of just asking 04:43:25 http://www.microchip.com/wwwproducts/Devices.aspx?product=PIC32MX460F512L is it 04:43:48 though i don't think that mentions the mmu. well, you could always check the thousand pages of manual 04:44:15 Microchip manuals are fun 04:44:27 you know how most systems have UB, and things you shouldn't do in case they break in future? 04:44:46 Microchip lets you know what happens if you do them anyway, and even give advice on it 04:45:08 let's see, i think i remember reading from some of the pseudoregisters being undefined 04:45:09 "this register's designed for programming the UART, but you can just use it for an extra byte of storage if the UART isn't active" 04:45:21 yeah pretty much 04:45:40 Bicyclidine : it's a MIPS 04:45:46 yes, it is a mips 04:45:49 well, embedded mips 04:45:58 is that related to mmus 04:46:14 that would be kind of neat, actually, you could use the io ports for special atomically partiallyrewritable storage 04:46:27 a whole, like, 72 bits or something. homey 04:47:16 then I guess it makes sense that jumping to data would probably work 04:47:32 i don't understand the relevance 04:47:56 because it's a larger architecture and more general purpose? 04:48:04 ok 04:48:07 i mean i literally don't know 04:48:25 like it's a small version of a general purpose CPU 04:54:14 with many nice things like a single cycle multiply :D 04:55:15 oh, i guess you can save cycles by doing that and then the multiply-add things etc before putting it back into core regs, huh 04:57:43 32k ram 05:06:15 madbr: a single cycle multiply at what clock speed? 05:06:44 80 MHz max on this gizmo 05:07:33 that's faster than a pentium 05:08:27 for integer multiply, anyways 05:24:12 most things these days are faster than a pentium :P 05:24:48 (except when they're much more energy efficient or something) 05:30:06 VHDL generates single cycle multiplies by default 05:30:11 you can end up using a lot of silicon if you don't pay attention 05:35:56 just with the * operator& 05:35:57 ? 05:38:48 yes 05:39:48 really intrigued about vhdl (and verilog) 05:42:10 they're basically the same language with different syntax, at this point 05:42:16 because they each stole each others' features 05:42:30 makes sense 05:42:56 the basic difference is that VHDL requires you to declare everything very precisely (and often multiple times), whereas Verilog ignores all that nonsense and often doesn't complain about typos as a result 05:43:35 learning a bit of verilog atm (mostly because it's more C++ like) 05:43:55 but I have no way to simulate code so it's all pie in the sky anyways 05:44:30 huh? simulators are pretty easily obtainable 05:44:41 GHDL is the one I use for VHDL; I hear Icarus is pretty good for Verilog 05:45:09 and both of them are in the Ubuntu repositories as of right now (ghdl, iverilog) 05:45:40 * madbr looks up icarus 05:45:51 meh, uses cygwin :/ 05:45:56 better than nothing tho :D 05:47:14 oh right, it actually hadn't crossed my mind that someone doing development might be using Windows 05:47:23 it's not impossible, just unexpected 05:47:45 I do DSP code for pro audio guys 05:47:54 that's 99.99% win32 and mac osx 05:48:19 right 05:48:43 at least one person I know finds Windows development so painful that they do it on Linux anyway ;-) 05:49:02 I like IDEs tbh 05:49:07 as specifically msvc 05:49:30 I know some guys like doing everything from the console and with strange text editors like vim 05:49:34 but that's not for me 05:49:55 When working on Linux I do use vim. 05:50:02 and I never got into the unix culture 05:50:22 doesn't appeal to me 06:12:09 for instance, to me the only appeal of the console is that it cuts down on development time for small tool applications (that don't need a GUI) and that it permits batch scripting 06:12:36 for other things, there's no point to it 06:12:55 I happen to like it, especially in UNIX systems 06:13:45 like, for me, it's always better to just use the OS's file management 06:14:19 what if you want to make a mass change? 06:14:32 that falls under batch scripting 06:14:37 Of course it helps to type fast 06:14:40 something as simple as "move all the files with the extension .nh4ct into another directory" is awkward (but possible) to do via the GUI 06:14:51 But anyone who should use a computer should learn to type fast. 06:14:59 the reason I find CLI more useful is that these operations come up all the time 06:15:14 ais523 : I'd change file odering to sort files by extension, then select all of them, then copy/paste/move 06:15:15 There are even prorgams that combine GUI and CLI if you like that. 06:15:39 madbr: right, that's what I meant by the "possible" 06:15:55 I'd still rather do that than use the console 06:15:56 to me, it seems a little insane that you have to mess with persistent settings like file ordering in order to do a simple task like that 06:16:18 which means navigating though a whole bunch of folders by pure text 06:16:46 then more or less blindly typing down the whole destination path in the copy command 06:17:13 tab speeds up all the typing but I'd still rather use the file manager 06:17:13 For example you could even have a terminal emulator, that allow escape codes and keyboard commands you can bring up a menu of the files and then you can click on them to select which ones you want, while is still as command-line normally. Even such thing as with mouse highlight and then middle-button to paste it, is another thing to do 06:17:28 madbr: normally I can type the name of a folder faster than I can find it in a GUI file manager 06:17:31 ais523 : file ordering is not a persistent setting 06:17:32 using tab-complete 06:17:39 and it persists on Windows, I think 06:17:49 well, yeah I guess it does persist 06:17:52 If there is enough room on the screen, the tab completion can be in another window too to display the stuff, you can then continue typing, use tab, and/or to click on the files you want. 06:17:54 but it's meant to be dynamic 06:18:05 basically you're just changing how they are displayed 06:18:30 also I navigate by typing the first letter of folders etc 06:18:38 which comes out about as fast as tab-complete 06:19:02 the other thing is, I like seeing the files I'm manipulating 06:20:00 What would be your opinion of these of my ideas that you can combine with CLI and GUI that can be used together? 06:21:15