dottrap

no profile record

Submissions

Lua 5.5.0 (rc1) has been released for testing

53 pointsby dottrap8개월 전2 comments

Lua 5.5.0 (Beta) Released

10 pointsby dottrap작년1 comments

comments

8개월 전discuss

Microsoft's timing was the worst. I think they announced this a year after Swift was already announced, but before Swift was open sourced. So Microsoft wouldn't be able to deal with things like Obj-C/Swift interop which iOS developers were already jumping onto. And Microsoft's Windows 8 mobile initiative was pretty clearly a flop by this point.

Frankly, this Obj-C effort needed to be done way earlier, starting with AppKit, like back when Microsoft was panicking that OS X 10.4 Tiger was going to kick Longhorn's butt. If these tools had already been proven useful before the dawn of the iPhone, Microsoft might have had a chance of riding the iOS wave.

Main changes (since 5.4)

  declarations for global variables
  for-loop variables are read only
  floats are printed in decimal with enough digits to be read back correctly.
  more levels for constructors
  table.create
  utf8.offset returns also final position of character
  external strings (that use memory not managed by Lua)
  new functions luaL_openselectedlibs and luaL_makeseed
  major collections done incrementally
  more compact arrays (large arrays use about 60% less memory)
  lua.c loads 'readline' dynamically
  static (fixed) binaries (when loading a binary chunk in memory, Lua can reuse its original memory in some of the internal structures)
  dump and undump reuse all strings
  auxiliary buffer reuses buffer when it creates final string

One of Lua's goals has been extreme portability, and the main implementation works on anything that has a C compiler, going to the extreme of compiling cleanly on C89, C99, and even compiling as C++ (no extern "C"). Remember that Lua is popular in the embedded space too, so this is a big feature.

Pallene isn't designed to be a new native language on its own. Pallene is designed to be a companion language for Lua, specializing in a subset of performance.

But as importantly, Pallene isn't just compiling to C. Pallene is generating C code that directly manipulates the underlying Lua internals, which are in C.

The research thesis is that many bottlenecks are due to boxing and unboxing going through an FFI. Memory safety also incurs overhead. Python is an extreme example of how excruciatingly slow this can be, but even Lua incurs costs for this. A core tenant of the Pallene compiler is that it can generate C code that gets to cheat like crazy. Pallene gets to directly access Lua internals and things like arrays directly manipulate underlying C arrays deep inside, which sidesteps boxing/unboxing. The compiler can do the analysis to make sure it doesn't cheat in a way that is unsafe. Finally, the C optimizer now also has a chance to perform optimizations. And now operations such as crunching math on arrays of numbers may get much faster because now you get generated code that is more CPU friendly and may benefit more from prefetching and cache locality.

Pallene is built from the the extreme compatibility goals as Lua since it is designed to work with it. It it only depends on any C compiler and Lua itself. If you get Lua compiled, then you can get Pallene working. That means any existing project that uses Lua (5.4) could start adding Pallene modules to their project for new features or to try to improve performance in key areas. Since Pallene just outputs a Lua modules, it looks like any other Lua module implemented in C, so it won't create new portability constraints that you didn't have before. This is different than say LuaJIT, where not all platforms may allow JIT or you may be targeting a new CPU architecture that LuaJIT does not support.

Both Teal and Pallene were started by grad students of Roberto's. Since Roberto has started giving talks himself on Pallene, I'm assuming they are joining in.

>> I really wish the Lua authors would add official types to Lua.

> Never going to happen IMO. Adding static types would change the nature of the language completely, even more than it has in Python.

You both are kind of right.

The Lua authors have been working on the new companion language to Lua named Pallene. Pallene is a subset of Lua that adds types, not for the sake of types themselves, but for the purpose of performance. The Pallene compiler can generate optimized native code that potentially removes the need to manually write a module for Lua in C.

The other cool trick is that Pallene and Lua are completely interoperable with each other, so Pallene can be added to existing Lua projects, and you can opt to use regular Lua for the dynamic parts of your code where compilers won't be able to optimize much and strong types might be more trouble than help.

Here is a talk Roberto Ierusalimschy gave about Pallene. https://www.youtube.com/watch?v=pGF2UFG7n6Y

2년 전discuss

This should be plenty fast. SDL_RenderCopy generally should be doing things the 'right' way for on any video card made roughly in the last 15ish years (basically binding a texture in GPU RAM to a quad).

You probably need to due some debugging/profiling to find where your problem is. Make sure you aren't creating SDL_Textures (or loading SDL_Surfaces) inside your main game play loop. You also may want to check what backend the SDL_Renderer is utilizing (e.g. OpenGL, Direct3D, Vulkan, Metal, software). If you are on software, that is likely your problem. Try forcing it to something hardware accelerated.

Also, I vaguely recall there was a legacy flag on SDL_Surfaces called "hardware" or "SDL_HWSURFACE" or "SDL_HWACCEL" or something. Don't set that. It was a a very legacy hardware from like 25 years ago that is slow on everything now.

2년 전discuss

I was referencing the historical motivations that led to where we are today. Yes, I was referring in part to the SDL_Render family APIs. These were insufficient to support things like Nuklear and Dear ImGui, which are reasonable use cases for a simple 2D game, which SDL hoped to help with by introducing the SDL_Render APIs in SDL 2.0 in the first place.

https://www.patreon.com/posts/58563886

Short excerpt:

    One day, a valid argument was made that basic 2D triangles are pretty powerful in themselves for not much more code, and it notably makes wiring the excellent Dear Imgui library to an SDL app nice and clean. Even here I was ready to push back but the always-amazing Sylvain Becker showed up not just with a full implementation but also with the software rendering additions and I could fight no longer. In it went.

The next logical thing people were already clamoring for back then was shader support. Basically, if you can provide both batching (i.e. triangles) and shaders, you can cover a surprising amount of use cases, including many beyond 2D.

So fast forwarding to today, you're right. Glancing at the commit, the GPU API has 80 functions. It is full-featured beyond its original 2D roots. I haven't followed the development enough to know where they are drawing the lines now, like would raytracing and mesh shaders be on their roadmap, or would those be a bridge too far.

2년 전discuss

This is a separate thing with the same name. Although both share some common ideas. The grimfang4/sdl-gpu is a separate library used with SDL, while the new SDL GPU API is directly part of SDL. grimfang4/sdl-gpu is much older and works with today's SDL 2.

The grimfang4/sdl-gpu was one good way to take advantage of modern GPUs in a simple way and workaround the holes/limitations of the old SDL 2D API. The new SDL 3 GPU API will likely make the need for things like grimfang4/sdl-gpu redundant.

2년 전discuss

The old SDL 2D API was not powerful enough. It was conceived in the rectangle sprite blitting days, when video hardware was designed very differently and had drastically different performance characteristics. If you wanted anything more, OpenGL used to be 'the best practice'. But today, the landscape competes between Vulkan, Metal, and Direct3D, and hardware is centered around batching and shaders. Trying to target OpenGL is more difficult because OpenGL fragmented between GL vs. GLES and platform support for OpenGL varies (e.g. Apple stopped updating GL after 4.1).

A good example demonstrating where the old SDL 2D API is too limited is with the 2D immediate mode GUI library, Nuklear. It has a few simple API stubs to fill in so it can be adapted to work with any graphics system. But for performance, it wants to batch submit all the vertices (triangle strip). But SDL's old API didn't support anything like that.

The reluctance was the SDL maintainers didn't want to create a monster and couldn't decide where to draw the line, so the line was held at the old 2D API. Then a few years ago, a user successfully changed the maintainers' minds after writing a demonstration showing how much could be achieved by just adding a simple batching API to SDL 2D. So that shifted the mindset and led to this current effort. I have not closely followed the development, but I think it still aims to be a simple API, and you will still be encouraged to pick a full blown 3D API if you go beyond 2D needs. But you no longer should need to go to one of the other APIs to do 2D things in modern ways on modern hardware.

2년 전discuss

Where did you see that? I'm skeptical of that claim because I know some embedded uses of Lua strongly utilize pre-compiling to Lua bytecode so they can keep their hardware as slim as possible. I know some will even strip out the Lua compiler from the binary they ship to shrink the profile even more. Also, many video games like to pre-compile their shipped Lua scripts to reduce their load times.

I know that the Lua team has internal private repositories, and that luac is developed in a separate repo for them. I've seen occasional reports on the Lua mailing list that luac.c is forgotten or not updated in non-official releases. That is because those source drops didn't go through the full official release process which includes merging in from their luac repo. Maybe you are confusing these intermediate source drops with deprecation? If there is deprecation, I would like to see the details on that. I presume they would be introducing some kind of replacement that addresses all the real world use cases that rely on the abilities of pre-compiling to Lua bytecode.

2년 전discuss

As another extremely simple idea, in my personal experience, just using regular Lua table syntax for serialization and then pre-compiling it with luac so it could be loaded quickly via dofile(), produced results just as fast for loading it in as using lua-protobuf. (I don't remember the difference between writing out Lua tables vs. lua-protobuf because my use case needed to read the data more often than generate it, but it must have not been big enough, if any, otherwise I would probably remember it.) I was loading gigabytes of data for large batch processing.

3년 전discuss

> IMHO there wasn’t any reason to bother fiddling with the definition of BOOL.

There were good reasons to change this to a real boolean. I think it was a WWDC, where kind of discussing this topic, one Apple engineer said they did an audit of production Obj-C code and found multiple instances where their BOOL values were values other than 0 or 1 (which was considered surprising and ultimately bugs).

This can lead to all sorts of subtle problems. One common one encountered by framework users is where something returns a BOOL and the user explicitly compared against == YES or == NO. If the value is say 2, then this code usually results in wrong decision.

3년 전discuss

As a historical note, this was also a thorny issue for language bridges to Objective-C, going beyond just Obj-C++. I'm thinking of bridges like PyObjC, RubyCocoa, CamelBones, and LuaCocoa.

BOOL was one of those things that would have been really nice to be a real bool because when bridging to other languages that had a real boolean type, the idioms could be completely natural when writing in the bridged language. But since BOOL was a 'signed char', using only the Obj-C runtime introspection, this by default would typically bridge to something weird like an integer.

In Mac OS X 10.5, Apple officially supported PyObjC and RubyCocoa, and introduced "BridgeSupport" which provided additional metadata and dylibs containing symbols for inline functions, so any language could create a full bridge to Cocoa. The metadata could be used to interpret if a 'signed char' could actually be used as a boolean or not. But BridgeSupport was not available for 3rd party APIs (unless the authors decided to support it, which was almost never).

There were bug requests filed for Apple to properly redefine BOOL to a real boolean for the 64-bit Mac ABI, before Apple had finalized it, but Apple didn't fix this in time. My memory is hazy, but I think when the iPhone ABI came around, they didn't have time to address this. So it would be another full arch ABI before there would be a chance to address this again.

3년 전discuss

I saw a few presentations from the 280 North guys. It was clearly impressive what these 3 guys built. Learning from Cocoa/Objective-C/Interface Builder well, they realized they needed to build 3 separate, but interconnected things, the framework (Cappuccino), the language (Objective-J), and the GUI builder (Atlas).

They sold to Motorola for $20 million in 2010, and that was the kind of the last I heard.

https://news.ycombinator.com/item?id=1631002

3년 전discuss

The food, including Cajun & Creole, crawfish, The French Quarter, Mardi Gras, voodoo, bayous, the music (birthplace of jazz), Louis Armstrong, Fats Domino, Jerry Lee Lewis, salt domes/caverns (which is why much of the US Strategic Petroleum Reserve is located there), the template for haunted mansions and graveyards.

Happy Turducken Day :)

3년 전discuss

I don't know about outside the US, but the impression I have is, Star Wars toys have mostly been a universal bust, especially of the items that are from new Star Wars and not the original. You can find a lot of info if you search about Rose Tico toys. The Tico toys aren't necessarily the worst (e.g. Admiral Holdo toys), but fans/critics like to use the Tico toy as demonstration of how badly Disney has miscalculated their Star Wars strategy.

Baby Yoda toys were an exception to the rule. But even Baby Yoda toys have their own story of missteps in this saga. Disney was caught completely flat-footed by the success of Baby Yoda and did not have any toys ready to go at the launch of The Mandalorian. Disney was overcompensating for the toy disaster after all the movies, (which also made their toy make partners very unhappy). (I think Hasbro is one of the main suppliers.) Then when Baby Yoda was a surprise hit, and fans were going to things like CafePress out of desperation for anything, Disney desperately scrambled to get anything out as fast as possible. If I recall, they had to bypass their normal partner Hasbro and go to Mattel just to get something to market fast. This is almost unheard of.

Baby Yoda is the only merch hit they have, but there are now retailer signs showing demand saturation. And for Star Wars fans who follow all the shows, like The Mandalorian, people are saying it looks like Baby Yoda was supposed to have left the show, completing his arc around the end of season 2 or The Book of Boba Fett. But rumors say, Disney desperate to keep Baby Yoda in the spotlight, forced him back into the show, with rumors Baby Yoda is going to appear in a bunch of other future Star Wars shows, like the new Rey Skywalker-Palpatine show.

I also forgot to mention the The Star Wars Galactic Cruiser experience. People also keep track of open bookings in that hotel and show it is mostly empty. There are lots of estimates of how much this cost to build and what the operating expenses are (all this is very expensive), and it once again indicates this is a massive money loser for Disney.

3년 전discuss

Thank you for identifying that. I felt a bunch of things were off in that screenshot. For one, I don't remember those colors. But I didn't trust my memory.

But more importantly, since the article went on to describe the "octopus" and other aliens in some detail, I was looking at that picture trying to see those details. None of those aliens were quite as I remembered them. That Atari 2600 picture really doesn't do justice to what the article goes into detail about.

3년 전discuss

Lots of indies keep close track of Disney. Many of them have a good understanding of the cost structures and revenue splits, and every time somebody does a breakdown of the numbers, Disney is bleeding red ink with the Lucasfilm acquisition. It's a complete boondoggle for Disney.

This is just one example breakdown of the numbers:

https://practicaleconomics.org/category/star-wars/

We also know that Disney+ is hemorrhaging tons of money. Disney reported something like a $1.1 billion loss in 2003-q1, and $1.5 billion loss the previous quarter. This is like Disney sinking one of their cruise liners every quarter. Neilsen streaming ratings have shown Star Wars shows have completely fallen off and have failed keep Disney+ competitive.

There are also tons of stories reported about how the Star Wars toys have failed to sell, and retailers were fire selling everything trying to get rid of the merchandise.

3년 전discuss

I got to speak to a couple different Apple file system engineers many years ago over the course of many WWDCs. I think it was around the Leopard or Snow Leopard time frame (2007-2009), where we casually discussed some of the challenges Apple was having with their ZFS effort.

(We didn't talk about iPhone, so either it had not been announced yet, or development was still so closed down, that it never came up as a topic of consideration.)

My recollection was with their ZFS work, while it was clear to everybody that Time Machine should be a big benefactor of ZFS, they were still unhappy with the high RAM requirements (and also not thrilled about the high CPU requirements). Since laptops were then the bulk of their sales, and these machines shipped with much more constrained specs, there was a lot of uncertainty about when/if they were going to make ZFS the default file system.

(Looking it up, the base 2006 Macbook had 512 MB of RAM, and shared RAM with the Intel GMA 950 GPU.)

I recall there always was a secondary backdrop of concerns with the ZFS license and also the fate of Sun, but the engineers I spoke with weren't involved in those parts of the decision making process.

3년 전discuss

Gold is classified as a commodity. The Commodity Futures Trading Commission (CFTC) is the federal government agency that regulates the commodity futures and other commodity derivatives, not the SEC.

7년 전discuss

And as another example, Mac OS X (10), which debuted in 2000, has had every subsequent version continued to be named 10.X. Just this week, macOS 10.15 Catalina was released.

Funny that the name Mac OS X went to OS X and then (back) to macOS, but the 10.X name persists.