1 / 31

Parrot in the Real World

Parrot in the Real World. Dan Sugalski dan@sidhe.org. A Presentation in two parts. Part 1 - The practical project Part 2 - The ramifications. Yarde Metals. Metals wholesaling company $200M+ year 400K+ items/year 400+ employees 6 branches. Metaltraq.

geraldlee
Download Presentation

Parrot in the Real World

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Parrot in the Real World Dan Sugalski dan@sidhe.org

  2. A Presentation in two parts • Part 1 - The practical project • Part 2 - The ramifications

  3. Yarde Metals • Metals wholesaling company • $200M+ year • 400K+ items/year • 400+ employees • 6 branches

  4. Metaltraq • Whole company run on a package called Metaltraq • Handles sales, shipping, tracking, invoicing--pretty much everything • We have the source, all 460K lines of it • Unfortunately it’s in DecisionPlus

  5. System Setup • Whole company runs on a single server • All terminal-based access • ISAM database, one index per data file • Only access to data through DecisionPlus

  6. Reports Screens DecisionPlus Language Basic Architecture Engine Database Screen

  7. The Problems • The underlying database engine has size issues • Integrated database is all ISAM • DecisonPlus, as a language, is nasty • Stuck on SCO Unix as a platform

  8. The size issues • Each data file has a maximum size limit • Our most active only holds about 17 months of data • That was 18 months a while back • Good for the company, bad for MIS

  9. ISAM. Ick • The only access to the data is via DecisionPlus • One index per table • Serious performance issues if you don’t use that index • Any data queries need MIS help

  10. DecisionPlus • Antique 4GL • Slightly more primitive than Parrot’s assembly language • No subroutines, just labels, goto, and gosub • No blocks, just continued lines • Limits on the length of a single line • No lexicals. Or, really, globals • Phenomenally primitive array access

  11. Two language versions • Forms, with screen interface • Reports, with looping, totalling, and cross-reference file support • Two versions of the same language, subtly different

  12. SCO Unix as our platform • Need anything more be said?

  13. The Original Plan • Move database to Postgres • Compile all programs into Perl • Dump original source • Do all new work in Perl

  14. It was a good plan… So, of course it was doomed to failure Sort of

  15. Transition to Postgres worked • We play trigger games to simulate ISAM behaviour • Auto-generate the “ISAM key” • DB thunking layer knows how to use this info • Nightly transfer gives us an up-to-date data warehouse • Already in production use

  16. Destination: Perl… not so good • DecisionPlus is really primitive • No subroutines or functions, just labels you can goto and gosub to • No lexical variables either • Or, technically, any variables at all • The generated perl was horrible

  17. Perl really isn’t a target language • Working around the scoping issues was… interesting • The resulting code looked like machine-generated code and wasn’t really editable • It was so non-perl that working with it would’ve really hurt • Performance penalties with no win

  18. The New Plan • Target Parrot instead • We had the parser • We had a working compiler • Parrot was working fine

  19. Balancing the Issues • Parrot gave us multi-language capabilities • Most of which were theoretical • Engine was fast • But… untested • So we did the sensible thing--a test run

  20. The Test • Get a simple screen running • Jan 9th deadline • Made it with hours to spare

  21. Pretty big test • Working DB access library • Working screen access library • 70% of the language

  22. What we have • 6K lines of PIR code in support libraries and class libraries • ~660 line DecisionPlus Parse::RecDescent grammar • 5K line compiler in perl • Full interface to Postgres & ncurses • No C code at all

  23. Project Status • Currently in-house beta • August general beta • Looking for a September or October rollout • Still got some things to thump, but they’re almost all compiler and runtime things • One big parrot bug

  24. What this did for Parrot • Didn’t alter the design, though it did change the timetable some • Multimethod dispatch • Objects • Dynamic bytecode loading • Stress-tested Parrot a lot

  25. The Ramifications • Really nice target for many languages • Generating code is really, really easy • Interfacing’s simple • Dynaloading’s handy

  26. Nice target • Parrot maps well to procedural languages • Object and MMD systems makes custom data types simple • Surprisingly stable

  27. Easy code generation • AST->PIR translation is trivial • Parrot hides a lot of the tricky stuff • Calling Conventions • Register coloring • Instruction set maps nicely to most languages

  28. C interfacing’s dead-easy • No C code needed • All with Parrot’s NCI interface • For a 2 hour hack it’s stood up really well

  29. Dynamic loading games work • Parrot’s built-in compilation system’s easy to use • Loading bytecode, assembly, or PIR work the same way • Bit limited with compilers right now, alas

  30. End conclusions • Compilers really aren’t tough • Parrot’s a nice target for compilers • Our cross-language features do work as we’d hoped • Moving a 4GL to Parrot is reasonably (potentially easily) doable

  31. Questions ?

More Related