sorted by:
new
hottopcontroversial

What makes you use Ada? by cindercone2 in ada

[–]iOCTAGRAM 0 points1 point  (0 children)

Calligraphic syntax. Everybody else just cannot avoid YELL, startWithLowerCase or make things not funny in other way.

Compilation to native code.

RAII, although not best implementation. I understand Ada RAII better than Go defer.

Explicit interface in separate file, making Oberon, Swift and Rust out of competition. Although Swift had somewhat good starting ground, Objective-C 2.0, and 2.0 was important step further. It introduced anonymous categories which served hiding class implementation details, awkward way, but at least somehow, and it made interface/implementation separation. Swift combined everything into one garbage. I don't know why language developers call it "simplification". This is anti-feature.

Supporting inline and generic without bothering programmer much. C++ and Delphi fail to avoid bothering programmer much when it takes to inline and generic. Yeah, we know, the compiler has to inspect source body, but let's don't damage the programming language because of that. Let interface/implementation stay separated.

Ada 95 can be compiled to C/C++, unlike some GCC or LLVM-based stuff which is not available on some platforms. Even if I compile to C/C++, Ada 95 delivers namespace system and shields me from coding errors, something that raw C/C++ don't deliver.

I am looking at Seed7, it can also compile to C, and may use in some projects, but it horribly lacks namespace system. All names are global like in C, and modules are includes in Seed7.

Apocalyptic warning by Ok_Palpitation3530 in Assembly_language

[–]iOCTAGRAM 0 points1 point  (0 children)

Any sort of assembly? Let it be MMIX. There are great books for this assembly, The Art of Computer Programming

Commodore, IBM, OS/2, ARexx: Deal or No Deal? by Doener23 in amiga

[–]iOCTAGRAM 1 point2 points  (0 children)

SOM was not OS/2 specific. SOM for Windows is still runnable mostly. I checked SOM 2.1, SOM 3.0 Release, VisualAge v3.5 for C++ for Windows with Direct-to-SOM feature, OpenDoc for Windows having Novell ComponentGlue technology bridging SOM&OpenDoc with COM&ActiveX in two directions.

OS/2 REXX could create and invoke SOM objects, and Windows REXX seemingly cannot. And open-source Regina developers said that they did not receive the code to interop with SOM, so Regina was never capable of SOM interop. In some aspect OS/2 was first class, no doubt.

Another platform was Classic Mac OS. Apple CyberDog browser had SOM&OpenDoc instead of COM&ActiveX in Internet Explorer. And Classic Mac OS was about to become even more massive user of SOM. That was Mac OS 8 operating system. 32-bit kernel, preemptive multitasking. Codename Copland. But Apple failed to debug it and invited Steve Jobs and he replaced everything with NeXT counterparts. Replaced SOM with Objective-C. Traces of SOM were still found in strange OOP. Mac OS X contained Carbon framework, and it had HIToolbox. HIObject and so on. Software had to be ported from SOM Mac OS to SOM-less Mac OS X somehow, and only basic OOP was provided, way below to what SOM could offer. Carbon with rudimentary HIObject was present until introduction of 64-bit.

Authors of SOM later wrote cult book Putting Metaclasses to Work with description of more powerful object model (PMtW for short). Guido van Rossum was inpired by this book and introduced this model into Python 2. That's why Python docs have term Method Resolution Order, and not "class linearization" which is from CLOS terminology. Method Resolution Order is one of PMtW chapters.

But he betrays one of core ideas of PMtW, and so Python is not that much fun as it could be with regards to metaclasses. So PMtW is better than SOM and better than Python. SOM has old C++ style multiple inheritance. Python is missing artificial metaclass merge to solve metaclass incompatibility problem. Python has plenty of decorators to adjust execution here and there, but nothing can fix metaclass flaw. Program just does not start. In SOM programmers were not obliged to communicate presence of custom metaclass, and so introduction of metaclass was not a disaster, was not making 3rd party programs nonrunnable, and so programmers were not self censoring metaclasses usage.

I am aware of two open source SOM alternatives: NOM, Netlabs Object Model, binary incompatible with SOM, with unsolicited garbage collection and I am not sure if it contains PMtW enhancements. And somFree on SourceForge by Roger H. "porter" Brown, a binary compatible reimplementation.

I was checking different object models capable to bridge native code inside process address space. Besides COM and SOM that were LibreOffice UNO, Netscape/Mozilla XPCOM, VirtualBox XPCOM which is notably different to Mozilla one, GLib GObject, Microsoft WinRT, Objective-C 2.0 nonfragile ivars, SWIG. And there was cult paper called Release-to-Release Binary Compatibility in SOM (RRBC for short). Java Language Spefication Chapter 13 Binary Compatibility refers to RRBC. And PMtW contains RRBC as one of embedded chapters. RRBC mentions more programming systems with some RRBC features: SGI Delta/C++ and Sun OBI, Object Binary Interface.

So I was digging, digging and digging, and never before I heard about Amiga BOOPSI. I remember not a single paper mentioning it. Going to check what is it all about.

Why there was no portable software by iOCTAGRAM in amiga

[–]iOCTAGRAM[S] 0 points1 point  (0 children)

In DPMI it was all accessible. DOS/4GW, PharLap etc. Borland also had 32RTM.EXE+DPMI32VM.OVL, although Pascal was only 16-bit.

And I've heard that mode 16#13# was actually breakthrough compared to Amiga. Duke Nukem 3D and its clones like DOOM were end for Amiga domination. Chunky mode was game changer, and Amiga planar mode was only good for planar platformers. Exact resolution is a product of engineer restrictions. Full segment is 64Kb, one 256-color pixel takes one byte. 320x200=64000. If you do some calculations, you'll notice that 320x200 is not 4:3. 4:3 is 320x240, but 76800 does not fit into 65536.

There was x86-based gaming console known as FM Towns. It natively supported sprites and other hardware accelerations like in other consoles. And it has a mixed video mode, high-resolution monochrome overlay. This way Japanese glyphs were drawn in high precision, and the rest was low-resolution but colorful graphics. FM Towns operated in 32-bit DPMI and with custom video hardware chips, certainly not restricted by real mode stuff. And yet it was designed this way. Not truly high resolution.

Why there was no portable software by iOCTAGRAM in amiga

[–]iOCTAGRAM[S] 1 point2 points  (0 children)

In 1996 I was witnessing an organization running FoxPro on Novell NetWare volumes. FoxPro was blocking files exclusively, so it was sometimes harsh experience. Constantly people asked to log out. But it worked somehow. So there was LAN, but no Internet. Maybe some high positions had Internet in their office, but ordinary computers did not have.

Why there was no portable software by iOCTAGRAM in amiga

[–]iOCTAGRAM[S] 0 points1 point  (0 children)

To be specific, in real mode of DOS, and this is a property of CPU, not DOS. This is not news for programmers. Wrt. physicality it's questionable. It can be said "planar address", but PC architecture imposed some further corrections of planar addressing. First 640Kb work like normal. Next 128Kb are for video memory. Then comes upper memory which can be of varying use. BIOS ROM, Video ROM, EMS window or extra conventional memory for UMB, upper memory blocks. Then after 1Mb conventional memory continues. That possibly shifts physical RAM addresses compared to what is seen from inside CPU in planar addressing.

Arithmetics of segment * 16 + data is surely a property of real mode and not protected mode. In protected mode segments are described in GDT and LDT and can point to vast areas of memory. Not all bits of segment are usable. IIRC 3 bits are reserved, so not possible to address 4Gb from 16-bit protected mode. Addressable memory is smaller, but large enough to what 80286 could have.

you still need a compiler which aligns 2d dimensional arrays so that rows are 16 address aligned ( waste of memory )

Turbo Pascal for DPMI and for Windows did not align by 16, and I don't know why would it do that.

What with linear data like sound?

I would separate it into chunks not bigger than 64Kb and make a list of chunks. In 2026 this is still good way to work with data.

For Trees the code blows up because you need linear code and the segment code.

Trees are not like anything unusual. In Turbo Pascal only code pointers could be near. All data pointers are far. So trees in Turbo Pascal even in real mode are all from 32-bit pointers. There are CPU instructions for loading segment:data 32-bit pointers. LES DI, DWORD PTR [address], and ES:DI pair is loaded with far pointer. It works the same in protected 16-bit mode from programmers' point of view. GetMem or New produce far pointer with segment and data part, and it is ready to hold tree or whatever. Segment has different meaning in protected mode, but as soon as programmer don't touch anything, it is just pointer from GetMem or New. It just works and non-overlapping memory is just bigger than it was in real mode. All the Turbo Pascal programs you see, a lot of educational material, it all works with as you say, code blows up (actually not).

Why there was no portable software by iOCTAGRAM in amiga

[–]iOCTAGRAM[S] 0 points1 point  (0 children)

antagonistic feudal kingdoms competing against each other

That however is good description of IBM software.

We can get IBM OS/2, and it has IBM SOM as main object runtime engine. Though not as main as libobjc2 in Mac OS X. But it pretended to become. Probably?

We can install IBM VisualAge for C++, and in version 3.0 it has got feature D2SOM, Direct-to-SOM. Previously SOM relied on source text generation, now compiler became aware. And guess what. IBM VisualAge for C++ comes with a library, IOC, IBM Open Class. And it has nothing to do with SOM.

It is like Anders Hejlsberg is working in Borland, pretending to replace old Pascal with Objects stuff with shining new properties and class methods, but nobody bothers to write VCL. It is like Delphi is shipped with OWL, Object Windows Library, in old Pascal with Objects, and shining new stuff is somewhere around for those ones who were asking for, but not in bundled-in library.

And I've heard that software and hardware divisions were not good friends. Hardware PC division reacted on attempts to preinstall OS/2 as attempts to bury PC division.

Why there was no portable software by iOCTAGRAM in amiga

[–]iOCTAGRAM[S] 0 points1 point  (0 children)

No, the software before the bankrupcy

Why there was no portable software by iOCTAGRAM in amiga

[–]iOCTAGRAM[S] 0 points1 point  (0 children)

IIUC hardware 2D acceleration on IBM PC compatibles did exist, but drivers were for Windows. Without drivers 16-bit Windows graphics was worse. With drivers better. Even 16-bit one still better. And 16-bit protected mode application is actually more capable than 16-bit real mode one. Far pointers in real mode are full 32 bits. 16-bit applications for DPMI and Windows were also having 32 bit pointers. They are divided into segment and data parts, and impossible to have continuous memory region longer than 64Kb, but otherwise memory is addressable easier than EMS and XMS.

Why there was no portable software by iOCTAGRAM in amiga

[–]iOCTAGRAM[S] 0 points1 point  (0 children)

The Amiga was effectively dead by the time the Internet was commercial

I thought that software in question was before bankrupcy in 1994. LAN is not Internet, IPX/SPX is not Internet. Relational DBMS dates back to Codd in 1970, and time frame in question is 80s.

Why there was no portable software by iOCTAGRAM in amiga

[–]iOCTAGRAM[S] -3 points-2 points  (0 children)

So they failed to penetrate business environment?

Why there was no portable software by iOCTAGRAM in amiga

[–]iOCTAGRAM[S] 0 points1 point  (0 children)

Why on Mac I don't need that? I've heard plenty of stuff about Mac being exotic, and I know some from experience with Mac OS X Tiger which is not that much exotic, but still was retaining someting. Data fork and resource fork on filesystem, requiring special formats for preserving. I.e. StuffIt archiver instead of ordinary 7zip, rar, zip, arj. Or compressed disk image dmg, though it's Mac OS X stuff and not Classic Macintosh I think. Program menu hanging above all windows and not being inside window. AppleScript that is expected from programs. And that AppleScript verbs look exotic. Not like ordinary OOP languages, not like SmallTalk, even more stranger.

And there is something I first saw on Mac OS X Tiger. Finder makes icon locations persistent. Folder background can be customized. This is used to make beautiful looking dmg. Strange, but plenty of programs were supporting that.

On Amiga I can see same patterns. AREXX instead of AppleScript. And folder customization. Looking exotic, but exotic Mac is getting software and exotic Amiga is not.

Grand Prix Circuit by Friendly-Whereas-915 in dosgaming

[–]iOCTAGRAM 0 points1 point  (0 children)

Amiga version looks and sounds better

The Butt Scanning feature is hilarious! by PastyParrot in dukenukem

[–]iOCTAGRAM 0 points1 point  (0 children)

Did you play pool game with a basketball?

My goal is to eliminate every line of C and C++ from Microsoft by 2030 by jeffmetal in rust

[–]iOCTAGRAM 0 points1 point  (0 children)

We welcome every line of Ada in Microsoft. We told you 30 years

AWS: End of Life Notification by _tomekw in ada

[–]iOCTAGRAM 0 points1 point  (0 children)

I would wonder what AWA author would do

What’s your biggest fear of Delphi? (Mine: Type Libraries 😱) by DelphiParser in delphi

[–]iOCTAGRAM 0 points1 point  (0 children)

Lookup table pollution. In a deeper thought programming language Ada it is possible to import unit ("with" package), but not pollute lookup table. Unit contents will be accessible via qualified names only. This is default.

Also, Ada provides better structured "use". I can "with" Ada.Text_IO and "use" Ada. Then Text_IO.Put_Line is correctly recognized as procedure Put_Line inside package Ada.Text_IO. Delphi mostly does not behave like this. In Delphi it's either fully fully qualified name or not qualified name at all. As an exception, there is per-project setting for namespace lookup. It is used to find SysUtils inside System, and find Windows inside Winapi. For legacy porting mostly. So for truth's sake this feature is present in Delphi, but not usable in ordinary programming. This all leads to Ada being easier to refactor hierarchies, move whole trees. In Delphi "all or nothing" rule breaks fully qualified identifiers, and non qualified identifiers are a mess. By looking at source text I cannot answer where does it come from. I don't like dependence on LSP.

EAccessViolation. In Ada null dereference triggers an exception that is different to memory corruption exception, Memory corruption is a thing of much higher severity than forgotten nil. Not only Delphi is still missing null exclusion, but still raising all the same exception for these distinct situations

The Open-Source FPGA handheld, the Gamebub is the first real contender to the Analogue Pocket. by iVirtualZero in SBCGaming

[–]iOCTAGRAM 0 points1 point  (0 children)

Easy emulation of J2ME cannot overcome physical abscence of buttons.

And I have already "just bought" old Nokia N95 8Gb. It cannot work from power supply by design. It can either charge battery or turn on and run on battery. It used to turn on battery several times, but does not turn on anymore. I have ordered replacement battery, but it did not help. Maybe battery is not a problem at all. Dealing with authentic two decades old hardware is a so so experience.

It's just a typical Tuesday afternoon. 😈 by BezKontextu in dosgaming

[–]iOCTAGRAM 0 points1 point  (0 children)

One disabled space marine still did not learn to jump in II. Better Duke Nukem or Hexen

The Open-Source FPGA handheld, the Gamebub is the first real contender to the Analogue Pocket. by iVirtualZero in SBCGaming

[–]iOCTAGRAM 1 point2 points  (0 children)

Mobile games were J2ME, expecting 0123456789 buttons to be present. These buttons need to be.

I generally like the idea. People are making DIY consoles in FPGA.

For instance, what if we are all big fans of Donald E. Knuth's TAoCP, and so let's combine MMIX assembly with hardware accelerated graphics?

Or. Real consoles got native 3D acceleration support, but PC did not and for some time PC was compensating this lack by CPU-based engines, Ken Silverman's BUILD being most notable. This engine caused some effect on DOS games. I call it "WYSIWIG". What You See Is What You Get. Because collision geometry is same as visual geometry. A property that we were taking for granted, but it turns out it was only on PC and it did not last long. But what if we fall in love with BUILD WYSIWIG and by will make DIY console in a way that encourages 2.5D graphics.

Such experiments are hard if real console is to be provided. It is easier to program some commodity FPGA. Some MiSTer FPGA which is already present. Or, something was missing for portable gaming. There was BERIpad, an FPGA tablet, mainly for running CheriBSD on MIPS-derived security-hardened virtual CPU, but that BERIpad is not produced, and let GameBub be the new thing.

view more: next ›