Author Topic: FluffOS-2.23  (Read 4826 times)

Offline wodan

  • BFF
  • ***
  • Posts: 434
  • Drink and code, you know you want to!
    • View Profile
FluffOS-2.23
« on: July 26, 2011, 04:24:47 pm »
http://www.fluffos.myzen.co.uk/fluffos/fluffos-2.23.tar.xz

FluffOS 2.23
added a terminal_colour_replace apply, this will be called with every string between two %^ delimiters, and will be replaced with whatever is returned.
fixed protocol number for GMCP
fixed sprintf code for MSSP uptime
added defer efun, it takes a function pointer that will be called when the current function ends (even if that was caused by a runtime)
the old range behaviour warning for negative array indexes is now optional
the driver can now be compiled to use either struct or class for structs, or even allow both
fixed crasher in uniq_array
fixed crasher in socket_status
added missing ',' in non iconv driver pcre support

Offline Nulvect

  • BFF
  • ***
  • Posts: 127
    • View Profile
Re: FluffOS-2.23
« Reply #1 on: July 27, 2011, 03:56:19 am »
Thank you for the addition of struct, the defer efun sounds mighty useful as well!

Offline quixadhal

  • BFF
  • ***
  • Posts: 642
    • View Profile
    • WileyMUD
Re: FluffOS-2.23
« Reply #2 on: July 27, 2011, 02:47:50 pm »
Just to have it clarified in text (rather than having to go look at the source)...

If I use terminal_colour_replace(), it will replace the text between the delimiters, or the text including the delimiters?

IE:  If the string "%^RED%^RED%^RESET%^" is being worked on, will the driver call terminal_colour_replace("RED"), and when I return "", do I end up with "RED%^RESET%^", or do I end up with "%^%^RED%^RESET%^"?

The reason I ask is, if it does the former, I can return "%^RED%^" to have it leave the code intact for a future pass with a different set of delimiters.  Yes, I have an actual use for that (user-defined color symbols).

I know, use the source Luke... *grin*

Thanks Wodan!

Offline wodan

  • BFF
  • ***
  • Posts: 434
  • Drink and code, you know you want to!
    • View Profile
Re: FluffOS-2.23
« Reply #3 on: July 28, 2011, 04:34:50 am »
it doesn't get the %^ going in, and the mapping is done after, however as this is after splitting up the text returning RED will be what gives you the red colour codes from your mapping.

so putting %^RED%^ in there will actually have that present in the resulting string, which seems to be what you wanted

Offline Holyavenger

  • Friend
  • **
  • Posts: 92
    • View Profile
#Define Malloc64?
« Reply #4 on: August 10, 2011, 07:02:53 pm »
When we choose a Malloc system, if we are on a 64 bit system do we have to:

 #define Malloc64 instead of #define SYSMALLOC?

Thanks

Offline wodan

  • BFF
  • ***
  • Posts: 434
  • Drink and code, you know you want to!
    • View Profile
Re: FluffOS-2.23
« Reply #5 on: August 11, 2011, 03:03:31 am »
no sysmalloc should always work, but malloc64 is likely to use less memory on a 64bit system.

Offline Holyavenger

  • Friend
  • **
  • Posts: 92
    • View Profile
Re: FluffOS-2.23
« Reply #6 on: August 15, 2011, 02:14:00 pm »
Wodan,

    Thanks for the quick reply. I have some feedback. I tried to compile v2.23 on SUSE 11.4 and had a complication,, whereas 2.22 compiled and works fine.
uname -va
Linux linux 2.6.37.6-0.7-desktop #1 SMP PREEMPT 2011-07-21 02:17:24 +0200 x86_64 x86_64 x86_64 GNU/Linux


GCC -v
lazy@linux:~/dragonfire/fluffos-2.23> gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.5/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.5 --enable-ssp --disable-libssp --disable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --program-suffix=-4.5 --enable-linux-futex --without-system-libunwind --enable-gold --with-plugin-ld=/usr/bin/gold --with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux
Thread model: posix
gcc version 4.5.1 20101208 [gcc-4_5-branch revision 167585] (SUSE Linux)

gmake main_build2
gmake[1]: Entering directory `/home/lazy/dragonfire/fluffos-2.23'
gmake -C packages 'CC=gcc -m64 -flto' 'CFLAGS=-D__USE_FIXED_PROTOTYPES__ -O3' 'OBJDIR=../obj' 'RANLIB=ranlib' 'A=a' 'O=o'
gmake[2]: Entering directory `/home/lazy/dragonfire/fluffos-2.23/packages'
gmake[2]: *** No rule to make target `../obj/dslib.o', needed by `all'.  Stop.
gmake[2]: Leaving directory `/home/lazy/dragonfire/fluffos-2.23/packages'
gmake[1]: *** [packages/packages.a] Error 2
gmake[1]: Leaving directory `/home/lazy/dragonfire/fluffos-2.23'
gmake: *** [main_build] Error 2

I manually copied these defines into local_options.ds and enabled MALLOC 64 (same script sans the struct stuff works in 2.22)

/* use class keyword for lpc structs */
#define STRUCT_CLASS

/* use struct keyword for lpc structs */
#define STRUCT_STRUCT

Also, starting with GCC 4.6-4.7 many of the obsolete OS's are being dropped. Moving forward, most of the PPC's, IRIX's etc are going to lose support.
http://gcc.gnu.org/gcc-4.7/changes.html . O

One other last observation, the build.MudOS.bat /win32 /windows I'm not sure these worked using MSVC in a long time. Windows ports are generally MingW and or Cygwin. Unless, someone writes an updated HOWTO these dirs can only cause confusion.

Finally, the configure script was missing from the 2.23 archive. I used a 2.22 one, perhaps that is the problem.

Anyhow, carrying the mudos torch to 2011+

Andrew


Offline Holyavenger

  • Friend
  • **
  • Posts: 92
    • View Profile
Re: FluffOS-2.23
« Reply #7 on: August 15, 2011, 04:23:00 pm »
Update
undef DSLIB

It works, yay!
 

Offline tigwyk

  • Acquaintance
  • *
  • Posts: 45
    • View Profile
Re: FluffOS-2.23
« Reply #8 on: September 23, 2011, 10:16:00 pm »
I had the same compile error, undeffed DSLIB and all is well!