- Haskell-Cafe - Haskell.org

Architecture for reflex based applications
by Robert Klotzner 02 Apr '18

02 Apr '18

Hi there! I did a little write up about structuring reflex applications, which seems to work out really well for me. Check it out here: https://github.com/gonimo/gonimo/blob/master/front/doc/Gonimo-Architecture.… I would love to hear your thoughts! Best regards, Robert

1 0

json-autotype 1.1.2, and type-providers initiative
by Michal J Gajda 02 Apr '18

02 Apr '18

Hi, I am pleased to announce new version of json-autotype. Highlights of the version: 1. GHC 8.4 support. 2. Preliminary support for Elm output (with more Haskell-family languages coming) 3. Peter Simons has joined the team as official maintainer. 4. Ask us anything on Gitter: https://gitter.im/dataHaskell/json-autotype Json-Autotype team, and Data Haskell Frames team is also pleased to announce `type-providers` initiative that aims to provide standard API for type providers for Haskell family of languages. (Please join us on Gitter: https://gitter.im/dataHaskell/type-providers and https://gitter.im/dataHaskell/DataFrames) -- Cheers Michal J. Gajda

1 0

Haskell mailing list etiquette
by Niklas Hambüchen 01 Apr '18

01 Apr '18

Dear mailing list participants, I recently discovered a document that contains, neatly enumerated, all the rules that we as a community follow today when discussing Haskell topics. Please direct Haskell newcomers to it as early as possible, so that they can learn our mode of working upfront, and don't have to discover it bit by bit. For everybody's convenience, I here are the key points: * When possible, refer all matters to committees, for "further study and consideration." Attempt to make the committees as large as possible. * Bring up irrelevant issues as frequently as possible. * Ask endless questions or engage in long correspondence about such orders. Quibble over them when you can. * Haggle over precise wordings of communications, minutes, resolutions. * Refer back to matters decided upon at the last meeting and attempt to re-open the question of the advisability of that decision. * Advocate "caution". Be "reasonable" and urge your fellow-conferees to be "reasonable" and avoid haste which might result in embarrassments or difficulties later on. * Be worried about the propriety of any decision - raise the question of whether such action as is contemplated lies within the jurisdiction of the group or whether it might conflict with the policy of some higher echelon. You can find the full list of rules here (refer to page 28): https://www.cia.gov/news-information/featured-story-archive/2012-featured-s… Best, Niklas

2 1

Proposal: Professionalizing GHC Development
by Gershom B 01 Apr '18

01 Apr '18

Fellow Haskellers, Recently there has been much work into creating a better and more professional GHC development process, including in the form of DevOps infrastructure, scheduled releases and governance, etc. But much remains to be done. There continues to be concern about the lack of use of industry-standard tools. For example, GHC development is tied to Phabricator, which is a custom product originally developed for in-house use by an obscure startup. GHC development is documented on a wiki still -- ancient technology, not appropriate for 2018. Wiki syntax for documentation needs to be replaced by the only modern standard -- github flavored markdown. Trac itself is ancient technology, dating to 2003, well before anybody knew how to program real software. It provides no support for all the most important aspects of software development -- Kanban boards, sprint management, or even burndown charts. What is necessary is an integrated solution that holistically addresses all aspects of development, fostering a DevOps culture, embracing cloud-first, agile-first, test-first, disrupt-first principles, and with an ironclad SLA. Rather than homegrown solutions, we need a GHC development process that utilizes tools and procedures already familiar to regular developers. Cross-sectional feature comparison analysis yields a clear front-runner -- Visual Studio Team Services. VSTS is a recognized Leader in the Gartner Magic Quadrant for Enterprise Agile Planning tools. It lets us migrate from custom git hosting to a more reliable source control system -- Team Foundation Version Control. By enforcing the locking of checked-out files, we can prevent the sorts of overlap between different patches that occur in the current distributed version management system, and coordinate tightly between developers, enabling and fostering T-shaped skills. Team Build also lets us migrate from antiquated makefiles to modern, industry-standard technology -- XML descriptions of build processes that integrate automatically with tracking of PBIs (product backlog items), and one-button release management. In terms of documentation, rather than deal with the subtleties of different markdown implementations and the confusing world of restructured text, we can utilize the full power of Word, including SharePoint integration as well as Office 365 capabilities, and integration with Microsoft Teams, the chat-based workspace for collaboration. This enables much more effective cross-team collaboration with product and marketing divisions. One of the most exciting features of VSTS is powerful extensibility, with APIs offered in both major programming paradigms in use today -- JVM and .NET. The core organizational principle for full application lifecycle management is a single data construct -- the "work item" which documentation informs us "represents a thing," which can be anything that "a user can imagine." The power of work items comes through their extensible XML representation. Work items are combined into a Process Template, with such powerful Process Templates available as Agile, Scrum, and CMMI. VSTS will also allow us to analyze GHC Developer team performance with an integrated reporting data warehouse that uses a cube. Pricing for up to 100 users is $750 a month. Individual developers can also purchase subscriptions to Visual Studio Professional for $45 a month. I suggest we start directing resources towards a transition. I imagine all work to accomplish this could be done within a year, and by next April 1, the GHC development process will be almost unrecognizable from that today. Regards, Gershom

4 3

Re: [Haskell-cafe] Proposal: Professionalizing GHC Development
by David Banas 01 Apr '18

01 Apr '18

What a lovely idea! Might I suggest that, in making this change, we also adopt certain elements from both: - the Cult of Relevance, and - complex drama based managerial hierarchy, so as not to miss out on the wonderful benefits of those two features of modern hive mind development. So glad we’re finally ready to be brave in this new World, -db

1 0

ANN: hledger 1.9
by Simon Michael 31 Mar '18

31 Mar '18

I'm pleased to announce hledger 1.9. The version jump signals some noteworthy changes still landing (normal-positive reports, budget reporting) which are a kind of preview of 2.0. The next major release, on 2018/06/30, will be hledger 2.0. Thank you to release contributors: Eli Flanagan, Peter Simons, Christoph Nicolai, agander, M Parker, Moritz Kiefer, Mykola Orliuk. hledger (http://hledger.org) is a reliable, cross-platform program for tracking money, time or other commodities, using double-entry accounting and simple plain text file formats. It provides command-line, curses and web interfaces, and aims to be a pleasant and practical tool for personal, business or institutional use. What's new ? ------------ Some highlights: * the "financial statement" commands bs/bse/cf/is now show all normal balances as positive numbers, producing more conventional financial reports which are easier to share with others. (experimental) * bal/bs/bse/cf/is can now generate HTML reports * account codes can be used to customize account sorting * numbers in scientific E-notation are supported, eg in journal and CSV data * budget report improvements * general report cleanups More at http://hledger.org/release-notes#hledger-1.9 . Get started ----------- See http://hledger.org/download for all install methods. Often, to get the latest release you will need to build it. Here are some ways to do that: Using the hledger-install script, which requires only bash and will build and install the hledger tools in $HOME/.local/bin/. (Note: building haskell apps can take significant time, memory, and disk space, especially the first time. You can kill and restart the installer without losing progress. If it fails, please help us improve it by reporting the full output): $ curl -O https://raw.githubusercontent.com/simonmichael/hledger/master/hledger-insta… $ less hledger-install.sh # (do security review) $ bash hledger-install.sh # (add -v for more detail; use bash -x to show commands being run) Using hledger-install the more convenient, less secure way: $ curl https://raw.githubusercontent.com/simonmichael/hledger/master/hledger-insta… | bash Using stack: $ stack install hledger-lib-1.9 hledger-1.9 # hledger-ui-1.9 hledger-web-1.9 hledger-api-1.9 Using cabal: $ cabal update $ cabal install hledger-1.9 # hledger-ui-1.9 hledger-web-1.9 hledger-api-1.9 After installation, ensure $HOME/.local/bin is in your $PATH. Now try some commands: $ hledger -h # quick help $ hledger help # list built-in manuals $ hledger add # record some transactions $ hledger # list available commands Now perhaps work through the tutorial at http://hledger.org/step-by-step.html Or review the fine documents, presentations etc. at http://hledger.org and http://plaintextaccounting.org Or say hello and ask questions in the #hledger IRC channel on Freenode: http://irc.hledger.org New users and contributors are always welcome! Give feedback, report bugs, send pull requests, write about it, etc. And if you have been finding hledger useful, consider becoming a sponsor or donor to help to sustain and accelerate our progress (see home page). Our IRC channel is #hledger on Freenode (http://irc.hledger.org)

1 0

Minimizing cascading rebuilds
by ☂Josh Chia (謝任中) 30 Mar '18

30 Mar '18

Hi, In my project, I have multiple packages. One of the packages, packageA, is very fundamental and depended on directly and indirectly by almost all the other packages. It has functions that use some hard-coded data (a ByteString top-level variable) also defined within packageA. This hard-coded data is appended regularly, causing packageA to be rebuilt and thus almost all the other packages to be rebuilt, and building takes a painfully long time. I know I can move this hard-coded data to a file that's read at run-time, but that means one more item to plumb in at run-time (where to find the file), and IO (preventing the functions from being pure), so I would like to keep it hard-coded. Is there an elegant way to prevent or minimize the cascading rebuild of the dependent packages just because the hard-coded data in packageA changed? For analogy, in C or C++, source code gets compiled to .o files, one for each .cpp source file. Multiple .o files get linked into executables. So, unless the interface (.hpp files) also change, an implementation (.cpp file) change does not cause dependents to be recompiled to get new .o files, although dependent executables get relinked. I'm not familiar with the compilation and linking logic in GHC so maybe it has additional complications. BTW, I'm using stack, in case it makes any difference to the nature of the problem. Josh

8 10

Haskell to Ethereum VM ?
by Takenobu Tani 30 Mar '18

30 Mar '18

Hi cafe, Does anyone know about the code generator from Haskell's syntax to Ethereum VM language (bytecode)? That is, what corresponds to Solidity in Haskell. Although Solidity is interesting, it's difficult for me to achieve quality and safety. Does such a project already exist? Regards, Takenobu

6 12

Re: [Haskell-cafe] Accelerating Automatic Differentiation
by Michal J Gajda 29 Mar '18

29 Mar '18

Hi Charlie It certainly looks like exciting project, but the bar is currently placed very high. TensorFlow package not only provides automatic differentiation for whole programs, but also optimizes data processing both on GPU, and reading to achieve large batches. This field has a lot of hot developments, so You would either need to propose something unique to Haskell, or You risk being outclassed by PyTorch and TensorFlow bindings Maybe Dominic suggests something too. Cheers Michal

5 9

ANN: network-2.6.3.5
by evan＠evan-borden.com 28 Mar '18

28 Mar '18

Announcing network-2.6.3.5 * Reverting "Do not closeFd within sendFd" [#271](https://github.com/haskell/network/pull/271) Sorry for any disruption this versioning snafu may have caused. https://hackage.haskell.org/package/network-2.6.3.5

1 0