FreeBSD as a development platform

I suppose you are talking about epmd, which supports distributed BEAM applications? You can run Elixir without it, and connected nodes authenticate via shared secret. You secure it like you would any other daemon.
 
At home, mainly Qt Creator. Using autotools (bleurg) for histroic reasons, which means GNU make GNU sed etc, which is a bit of a pain. The code is mostly half C (C without libc) using clang and GCC occasionally. More gdb than lldb because I use gdbserver (and haven't had time to implement lldbserver). Some asm and inline asm. clang doesn't support all of the inline asm that GCC does.
 
dap said:
I'm using x86 ASM, C, C++, Java and Python.
The only problem is that I couldn't find a COBOL compiler for FreeBSD that accepts the sources we write at school (with a proprietary compiler). I guess that COBOL must be quite standardized, maybe I just don't know how to write portable code with it. But it's not like I want to dig in this horrible language anyway. :x
The tool I use the most is Emacs. I also use SCons and Doxygen.
What I like with FreeBSD is that with only the first CD I have a quite complete programming environment with GCC, vi, common headers and libaries, Python and so on.
Click to expand...
 
I choose to do most for-pay projects in C++ where possible, and C when I need to touch the hardware. I sprinkle in a touch of python and Qt for RAP (rapid application prototyping) when appropriate. This goes to the types of projects I take on. They are not business support, but rather applied engineering.

In my personal/research world I will dabble with JAVA for platform portability and PostgreSQL for my DB needs.

exempting the above tool loyalties, I'm lazy and prefer to avoid coding if possible, then when necessary I look for the highest level tool to meet the stated needs, and to meet the inevitable scope creep.
 
Eponasoft said:
I use gcc for software development, and am working on a BASIC compiler for BSD. BASIC is under-represented in Unix altogether, and there don't appear to actually be any BASIC compilers for BSD, just a small amount of interpreters that "also compile in BSD". I don't use any other languages or compilers though, and I don't really know how many other languages are under-represented here.
Click to expand...
As an academic curiosity sure, but why...just why? BASIC, even with added extensions, is not great language, given the other options available. Of course I started with DEC BASIC and TRS80 ROM BASIC back in the stone age, then was forced to use the MS-BASIC hacks in the days of segmented PC memory models. Yuk!...brings back too many bad memories. LOL

point of inquiry...if you are working on a BASIC compiler then you are using C and the typical "dragon book endorsed" lex analyzers and parser generaters, right?
 
hark said:
Haskell, C and Python. Vim as the IDE.

I'm surprised no one's mentioned Perl yet.
Click to expand...
PERL? Is that a languge, or just garbled serial transmission line noise?

Was a time when I'd do 20 line PERL functions on the command line to process stuff, but haven't had the need in literally years and years. Stuff I used to do in PERL, I do in python these days, because while I dislike indentation sensitive grammars, I dislike the perl syntax even more.
 
Dab wrote.
What I like with FreeBSD is that with only the first CD I have a quite complete programming environment with GCC, vi, common headers and libaries, Python and so on.

I try gcc with no result. I use FBSD 13.1.disk.iso.
 
Last edited:
Rock said:
I try gcc with no result. I use FBSD 13.1.disk.iso.
Click to expand...
Ok, that's one of these "not sure if trolling" moments (nota bene 13.1 will be EoL by the end of this month) ... let's assume it isn't:
  • On any "Unix-like" system, the command cc should invoke the system's default compiler. So, just use this if you want to compile some C code (for C++, it would be, surprise, c++ instead). On your typical GNU/Linux system, they will invoke gcc (or, g++).
  • FreeBSD moved to using llvm/clang as its default compiler quite some time ago. So, you won't find a gcc in the base install. If you really want (or, need) gcc for whatever reason, you can install it from ports/packages. Most of the time, you don't.
 
On thread topic: For my personal needs (developing my private projects), FreeBSD is the perfect platform. What I do most:
  • POSIX C programs and/or libraries. No details needed I guess, FreeBSD can do that.
  • "Portable" C and/or C++ (in case I need a GUI, I prefer Qt for that) programs and/or libraries. The nice thing is, I can even cross-build to Windows (using MXE, needed some slight modifications to work on FreeBSD but it wasn't too hard to get it working) and to GNU/Linux (did something similar as MXE manually for that, just bootstrapping a GNU toolchain in a separate prefix targeting Linux was actually quite easy). Ok, I can't cross-build to MacOS, but I really blame Apple for that, it's a consequence of their locked-down platform. E.g. to just get the SDK files for targeting MacOS, you need X-Code, which needs a running MacOS, which needs original Apple hardware .... oh well, forget it, no MacOS support from me then :cool:
  • Cross-development for the good old C64. FreeBSD ports already had quite a lot of valuable tools like emulators/vice (which comes with an awesome "monitor" acting as a capable debugger) and devel/cc65 (a C compiler targeting MOS6502-based platforms that also includes a nice assembler and linker). I'm working on adding even more tooling around the C64 to our ports 😉
  • Cross-development to AVR embedded chips, all the necessary packages are there as well.
 
I don't write anything for the 'nix platform yet.
Lazarus is my choice for porting my Win32 Delphi code.
Up until now, I spent decades writing system level code in ASM, C and Delphi.
Now, I'm spending far more time writing VBA for Excel, than for system level use.
 
kent_dorfman766 said:
As an academic curiosity sure, but why...just why? BASIC, even with added extensions, is not great language, given the other options available. Of course I started with DEC BASIC and TRS80 ROM BASIC back in the stone age, then was forced to use the MS-BASIC hacks in the days of segmented PC memory models. Yuk!...brings back too many bad memories. LOL
Click to expand...
A long, long time ago when I was at IBM, I wanted to test Microsoft compiled BASIC on the IBM PC 8088 against an Atari 800.
The test case was the Zmodem file transfer protocol I wrote in BASCOM for the PC and the Atari BASIC cartridge for the 800.

Despite the Atari running interpreted and the PC running compiled, the Atari wiped the floor with the IBM.
Bank switching the 808x processors just required you keep your head clear about what goes where.
Bank switching the add-on EMM cards was more bank switching but opened up a far larger (segmented) address space, which I never needed.

I switched to TASM and Borland C in those days to get away from the MS bloat.
 
bgavin said:
A long, long time ago when I was at IBM, I wanted to test Microsoft compiled BASIC on the IBM PC 8088 against an Atari 800.
The test case was the Zmodem file transfer protocol I wrote in BASCOM for the PC and the Atari BASIC cartridge for the 800.

Despite the Atari running interpreted and the PC running compiled, the Atari wiped the floor with the IBM.
Bank switching the 808x processors just required you keep your head clear about what goes where.
Bank switching the add-on EMM cards was more bank switching but opened up a far larger (segmented) address space, which I never needed.

I switched to TASM and Borland C in those days to get away from the MS bloat.
Click to expand...
Is a file transfer protocol really a valid test for such platforms though? I would suspect that the majority of bottleneck in the 8088 would be IO related since that was about the time that DOS started running defense between user programs and hardware accesss. I cannot remember if the UART was directly addressed via IN/OUT instructions or if the BASIC COMMs stuff went thru a seriously unoptimized abstraction layer in DOS.
 
I only code in a triple layered jail running within a hypervisor that can only be accessed from a random remote system (headless obviously). Once I'm in though, I use it write the finest HTML5.
 
bgavin said:
A long, long time ago when I was at IBM, I wanted to test Microsoft compiled BASIC on the IBM PC 8088 against an Atari 800.
The test case was the Zmodem file transfer protocol I wrote in BASCOM for the PC and the Atari BASIC cartridge for the 800.

Despite the Atari running interpreted and the PC running compiled, the Atari wiped the floor with the IBM.
Bank switching the 808x processors just required you keep your head clear about what goes where.
Bank switching the add-on EMM cards was more bank switching but opened up a far larger (segmented) address space, which I never needed.

I switched to TASM and Borland C in those days to get away from the MS bloat.
Click to expand...
The technical jargon is over my head. So you created the 0880 chip. Was Gates your buddy?
 
IBM opted to use the 8088.
Gates bought DOS from Seattle Computer, then re-sold it to IBM for a ton of bux.. the rest is history.
I had to chuckle... Gary Kildall (sp?) was first approached for his CP/M, but he was all anti-corporate and refused, and lost out big time.
All these years later, and the joke is still on him.
 
bgavin said:
Gates bought DOS from Seattle Computer, then re-sold it to IBM for a ton of bux.. the rest is history.
Click to expand...
This was IIRC called QDOS (QD for quick and dirty) and actually, MS fiddled a bit with it before it went to IBM. But the interesting part is this: It wasn't "sold" to IBM, but licensed in a way that ensured MS would be paid for copies and reserve all rights. That's because MS learned their lesson before with their real own product "Altair BASIC", later "Microsoft BASIC", which was licensed to manufacturers often in a way that they paid once and could do with it what they wanted, Commodore being a notable customer here 😉
bgavin said:
... CP/M ...
Click to expand...
And the "funny" part is: QDOS was heavily "inspired" by CP/M (or, you could say, it was a weak imitation of CP/M). It also attempted to "improve" things, like e.g. support for the CP/M devices, which were IIRC only implemented in CP/M's "pip" tool, in a more generic way – and got THAT horribly wrong. There's a reason you still can't name a file e.g. con.txt in Windows. 🤯
 
Rock said:
I don't know if PL\I is implementen in any FreeBSD.
Click to expand...
It's nearly impossible to find an open-source and free PL/I compiler. The only compiler I know of for Linux is shipped as a compiled binary, but it is free to download.

And it is completely impossible to find any compiler for PL/S, even though it is a very good language for operating systems development.
 
ralphbsz said:
And it is completely impossible to find any compiler for PL/S, even though it is a very good language for operating systems development.
Click to expand...
If a compiler is impossible to find, I'd think that's a strike against it being good for OS development... unlike GCC or LLVM. T.T
 
cracauer@ said:
In particular I can't really get into any of the usual scripting languages. It requires too my memory than I need for other things.
Click to expand...
That is one of the reasons I like tcl, but now it grew and has a lot of commands.

The other reason is the syntax. It reminds me Lisp, but with less parenthesis. I also like the way the name
and value of the variables are denoted. But this is a matter of taste, many people do not like tcl due
to the syntax. It is sensible to new lines, but that is by far not as ugly as the indentation sensitivity of
python. I would prefer perl over python.

I know only this scripting language, but have the impression, that syntax is the biggest / only difference
among them. Perhaps ruby is the exception?

But I am not a developer, I am just a computer user, and to that belongs making some programs one
needs. A computer is a programmable machine, not an application box.

I also learned a lot of languages, but now I use mainly tcl/tk, sqlite3, C, some posix tools like lex, of course TeX.
 
You must log in or register to reply here.
Back
Top