Author Topic: 2.27 ?  (Read 2530 times)

Offline FallenTree

  • BFF
  • ***
  • Posts: 484
    • View Profile
2.27 ?
« on: March 14, 2013, 05:10:17 PM »
Hey wodan, while the patches are accumulating on 2.27  , what's your plan ? do you have changes now , do you still want us to generate patches for you to release and merge ?  or do you rather just include your patches against 2.26.1 towards 2.27 altogether? no hurry on release though, just want to get ready when time comes.

Thanks.

Offline wodan

  • BFF
  • ***
  • Posts: 434
  • Drink and code, you know you want to!
    • View Profile
Re: 2.27 ?
« Reply #1 on: March 14, 2013, 07:16:05 PM »
I'll try and use git, if all else fails, I'll fire up the old VM with cvs on it like before.

Offline FallenTree

  • BFF
  • ***
  • Posts: 484
    • View Profile
Re: 2.27 ?
« Reply #2 on: March 14, 2013, 07:40:13 PM »
can you be more specific ?  I need to kind of know your intended workflow in git to know how this would be handled.

Offline wodan

  • BFF
  • ***
  • Posts: 434
  • Drink and code, you know you want to!
    • View Profile
Re: 2.27 ?
« Reply #3 on: March 16, 2013, 10:34:48 AM »
not really sure until i start, looking at the changes though, we may need to go to the old mudos alpha and beta branch style

Offline FallenTree

  • BFF
  • ***
  • Posts: 484
    • View Profile
Re: 2.27 ?
« Reply #4 on: March 17, 2013, 05:58:37 AM »
Here's a short summary of what is in next-2.27. Consider the amount of change, I would rather have it released sooner so people can test early.

Also, I've hooked our github with Travis CI, so after this release, we will get automatic build/test on every commit!!  with both clang & gcc. checkout this :

https://travis-ci.org/fluffos/fluffos

Important changes: 
  * changed VM icode for EFUN calls , previouslly single argument EFUN  + operaters is limited to 256 due to implemntation. and other EFUNS are also limited to 256. This has caused a few problem.  I reworked the way LPC VM calls EFUN, so now we can have totally 65535 EFUN + operators.
  * POSIX_TIMER support for higher precision profiling/eval cost limiting. (Voltara)
  * Guard against recursive callout("xx",0);  (Voltara)
  * Completely unbreak DEBUG_MALLOC + CHECK_MEMORY. everything is accounted for, it will be run as test to verify no leaks is introduced in new EFUN driver code.
  * Crypto package multiple fixes and enhancements  (Voltara)

Test changes:
  * Updated testsuite.
  * added "make test" to automatically run tests.

Build Changes:
  * Detect OSX and use clang.
  * Get rid of most compile warning by GCC. Havn't finish clang ones yet.
  * Simplified build system,  removed most of outdated stuff, only supporting GCC / CLANG now. Remove use of AR, RANLIB, SED.
  * Hooked up repo with travis CI, now we have true continuous integration.

Offline wodan

  • BFF
  • ***
  • Posts: 434
  • Drink and code, you know you want to!
    • View Profile
Re: 2.27 ?
« Reply #5 on: March 20, 2013, 06:19:33 PM »
ok. so I tried cloning the git thing, and what I got was not 2.26, how do I get that so I can base a next release on it?

Offline FallenTree

  • BFF
  • ***
  • Posts: 484
    • View Profile
Re: 2.27 ?
« Reply #6 on: March 20, 2013, 06:28:10 PM »
git checkout master

Offline wodan

  • BFF
  • ***
  • Posts: 434
  • Drink and code, you know you want to!
    • View Profile
Re: 2.27 ?
« Reply #7 on: March 20, 2013, 07:01:18 PM »
ah yes, much better :)

Offline FallenTree

  • BFF
  • ***
  • Posts: 484
    • View Profile
Re: 2.27 ?
« Reply #8 on: March 20, 2013, 07:09:39 PM »
The github way should be:

Click on "Fork' on the offical repo,  to have you onw, then git clone that,  commit and push, then send a pull-request  using web ui.

don't push directly to offical repo.

Offline quixadhal

  • BFF
  • ***
  • Posts: 642
    • View Profile
    • WileyMUD
Re: 2.27 ?
« Reply #9 on: March 21, 2013, 12:20:54 AM »
You can also change the "default" branch in git's repository options... so if you want to have a beta branch and a production branch, you can ensure people who just go to the github page and clone you, get the production branch as default.

Offline FallenTree

  • BFF
  • ***
  • Posts: 484
    • View Profile
Re: 2.27 ?
« Reply #10 on: March 21, 2013, 01:02:54 AM »
More test of next-2.27 is needed, I set default branch mostly because the old release contains the old readme file etc isn't really that useful.

Offline wodan

  • BFF
  • ***
  • Posts: 434
  • Drink and code, you know you want to!
    • View Profile
Re: 2.27 ?
« Reply #11 on: March 24, 2013, 08:49:30 PM »
I have been doing stuff for 2.27 this weekend, but didn't quite get to even testing if my current state compiles. If you're interested my current 2.27 tree is in dwwodan/fluffos FluffOS-2.27.

Not included from the patches I looked at so far:

commit ec89a4efa56882ad6d37565c909cb281859b078e
Remove old build craft in build.FluffOS.

There's no clear (to me at least) advantage for supported systems and it may break systems it has worked for so far.

commit 42880852a44c45c042af4741c90beba3c9f29f9b
Use clang by default on OSX.
depended on ec89a4efa56882ad6d37565c909cb281859b078e

commit ffb4474916b0b6237859738ffe84716feb4eeead
Properly detect OSX system.
same

commit 375a5e425536991984c670bf2ce0b2eaa622497f
Added protection against immediate call_out loops
I like the idea, but prefer it as a compile option (as this doesn't fit with the current dw behaviour)

commit 82265f801fd9db9e6db99ef07028615312c39af6
Fixup develop / debug build.
depends on the build system changes again


Still looking at the 65535 efuns change, it hits rather important bits of code, so perhaps that should sit in an experimental driver for a bit (we could start a 3.0 series for that)

This leaves me slightly over a week behind, hopefully I'll get closer (and get to actually run stuff) in the easter weekend.

I did look at a few of the other changes which is why I'll add this...
inline as used in the driver sources is ENTIRELY wrong, if you want to use proper inlining, start with removing all uses of the INLINE macro, whoever added those thought inline can work cross compilation units. Compiling with -flto will actually do that, but ignores inline statements, and not all compilers support it.

Proper inline useage would be using it for functions in the same file as where it is called, if there are more users it'll have to live in an include file as static inline (static to avoid link errors). I can't think of any reason to use an INCLUDE macro for it as it has been in the standard for many years now.

Offline FallenTree

  • BFF
  • ***
  • Posts: 484
    • View Profile
Re: 2.27 ?
« Reply #12 on: March 24, 2013, 08:55:16 PM »
There is some more patches that I submitted yesterday and today, including reverting the INLINE change, yes it is all wrong, and it should be fixed properly..

Still looking at the 65535 efuns change, it hits rather important bits of code, so perhaps that should sit in an experimental driver for a bit (we could start a 3.0 series for that)
It does, but the change is actually small, it would be good to have this tested.  Note that the 256 limit is already very close, one or two if you have a few packages.

Checkout the opcodes.h get generated,  and check BASE and ONEARG_MAX , it's very close to 256 , once beyond weird errors will start :-(