Comments
from Hacker News https://ift.tt/cUqb1VD
Wednesday, March 2, 2022
Lavish Roman mosaic is biggest found in London for 50 years
The largest expanse of Roman mosaic found in London for more than half a century has been unearthed at a site believed to have been a venue for high-ranking officials to lounge in while being served food and drink.
Dating from the late second century to the early third century, the mosaic’s flowers and geometric patterns were a thrilling, once-in-a-lifetime find, said Antonietta Lerz, of the Museum of London Archaeology (Mola).
It was discovered about a month ago at a construction site near London Bridge. The mosaic, which is eight metres long, will be lifted later this year for preservation and conservation work, with the eventual hope of it being publicly displayed.
Its main panel features large, colourful flowers surrounded by bands incorporating a twisted-rope design, set within a red tessellated floor. There are also geometric elements and lotus flowers in the main mosaic and a smaller nearby panel.
David Neal, an expert in Roman mosaic, has attributed the design of the larger panel to a team of mosaicists known as the Acanthus group, who developed a unique style. The smaller panel is a close parallel to one unearthed in Trier, Germany, suggesting that London artisans travelled abroad.
The archaeologists from Mola, who have worked at the site since last June, believe the room housing the mosaic was a triclinium, containing dining couches on which people would recline to eat and drink while admiring the decorative flooring. The walls were also richly decorated.
The triclinium may have been part of a Roman mansio, effectively an upmarket motel offering accommodation, dining and stabling to state officials and couriers travelling to and from Londinium across the river. The footprint of the building is still being uncovered, but it appears to have been a large complex around a central courtyard.
Another large Roman building was also found at the site, which archaeologists say was likely to have been the private residence of a wealthy individual or family. Traces of lavishly painted walls, terrazzo and mosaic floors, coins and jewellery have been found.
Among the items recovered are a decorated bronze brooch, a bone hairpin and a sewing needle. “These finds are associated with high-status women who were following the latest fashions and the latest hairstyles,” said Lerz.
It was “the heyday of Roman London”, she added. “The buildings on this site were of very high status. The people living here were living the good life.”
The site is being redeveloped as The Liberty of Southwark, a complex of offices, homes and shops that is a joint-venture by U+I and Transport for London (TfL).
from Hacker News https://ift.tt/AdYcwou
Tuesday, March 1, 2022
IPFS Backed by Decentralized Storage
Over the past two years, the NFT boom has taken the world by storm. Minting NFTs across various blockchains is now commonplace in the crypto world. However the storage of these NFT assets is often overlooked. IPFS, known as the InterPlanetary File System, has become the common standard used to store NFT assets.
One often overlooked detail is that IPFS is not a storage network in and of itself. It is much more of a data routing and transmission protocol. The IPFS network is a collection of nodes exchanging information. File entries can be "pinned" to the public IPFS DHT (distributed hash table) to let other nodes on the network know which hosts are storing which files. The tweet below covers it pretty well.
Within the IPFS ecosystem, there are a number of public gateways. Some of these gateways allow you to upload files, but there is often no guarantee that your file will remain online. Unless a file is explicitly pinned by an IPFS node, the file will simply be removed the next time the garbage collection process runs. This has surfaced a number of issues regarding the storage of NFTs.
To help solve this problem, a few different pinning providers have emerged. For a fee, these providers will allow you to upload your files, and they will keep them actively pinned for you. However this brings a new problem to light: where are these files actually being stored? Somewhere out there, an IPFS server is running and serving content, but where does the content ultimately live?
Filling in the gaps
At Filebase, we've spent a lot of time researching and analyzing this problem. We specialize in building on top of decentralized storage, and our flagship S3 compatible API has processed close to 1 billion files. Just a couple of months ago, we put our thinking hats on and started working on this problem. Here is what we found:
- Most IPFS pinning providers use Amazon S3 and other centralized object storage services under the hood. The "data store" of an IPFS server can be pointed to S3 using a simple plugin.
- Because AWS S3 is being used, providers are charging upwards of ~$150 per TB!
- However, if AWS S3 goes down, your IPFS server goes down too. Unless the data has been cached somewhere, your IPFS CID links are no longer accessible. This can result in an NFT "rug pull".
- A system with this configuration also has the net result of introducing a very fancy way to access AWS S3. If we are so reliant on AWS, why not use a simple HTTP URL instead?
Why not build Web3 with Web3?
We've come up with a solution to address the gaps listed above and we think it will benefit the entire crypto ecosystem. Simply put: Why not build Web3 with Web3?
Today, we are excited to share that Filebase now has support for IPFS!
Now you might ask - what makes this integration unique? It's simple: all files that are pinned onto IPFS using Filebase are actually being stored on Sia, one of the leading decentralized storage networks. This creates an environment where the data storage layer for our IPFS nodes is highly available, and most importantly, geo-redundant. By using a decentralized network for storage, we are no longer reliant on a cloud provider's block storage volume (AWS EBS) or a centralized storage bucket. (AWS S3)
A Filebase edge location could suffer a complete outage, and other locations will simply pick up the slack. This is made possible because the underlying data storage layer is decentralized.
Oh, and there's a massive cost benefit too: This is available to all Filebase users starting today, for $5.99 per TB while in beta. In the future, we may raise this pricing slightly based on usage patterns, but it will be nowhere near $150 per TB.
How do I pin data onto IPFS?
With Filebase, pinning data onto IPFS is easy. You have two options:
- Use our simple drag and drop interface within the Filebase dashboard
- Use our simple S3 compatible API
When you upload a file, an IPFS CID (content identifier) will be returned. You can then use this CID to access your data from your own IPFS node, or any other IPFS gateway on the public internet. CID's are clearly displayed within our dashboard, and they can be retrieved programmatically as well.
Once you've opened up an IPFS bucket from the dashboard, a CID column appears. You can click on any CID, and it will be automatically copied to your clipboard.
The object overview page will also show you the CID, along with other details:
If you're using the S3 compatible API, the CID will be returned in the response of a PutObject call. For example, if we run the following AWS CLI command:
aws --endpoint https://s3.filebase.com s3 cp test-images/7FIMFhlMf6A.jpg s3://ipfs-test --debugThe response is shown below. For convenience, we've highlighted the respective response header:
We can also call the HeadObject API to fetch the CID at any time as well:
aws --endpoint https://s3.filebase.com s3api head-object --bucket ipfs-test --key 7FIMFhlMf6A.jpg
Now that IPFS functionality is live, we plan to continue building out this integration even further! Be on the look out for additional upcoming features!.
Questions? Check out our excellent documentation found here, or simply reach out to us: [email protected] or by joining by our Discord.
from Hacker News https://ift.tt/5bCez2X
Conscription of Thought (1917)
Social psychologists, notably Mr. Trotter in his account of herd psychology, have described the peculiar mental effect of war upon the civilian population. Vague unlocalized anxiety and fear; dread of isolation, and desire for company to reinforce confidence and opinion; quick and easy accessibility to rumor, indeed, an eager hospitality to it; extreme credulity as to both good news and bad; a suspicious attitude which finds spies and enemies everywhere; scandalmongering of pessimistic inventions as to incompetency in high places and disloyalty in all places—these are some of the observed facts of mass-psychology in times of great emotional stir when the issue hangs in abeyance.
There is no need to reduce the variety of manifestations to any single principle. But running through them all is a demand for solidarity in order to prosecute war, combined with an emotional instability in the face of the shifting panorama of success and failure, an instability which is continually eating into solidarity. We have not suffered as yet in this country from a bad attack of war nerves; the scene is too remote. On a small scale, however, practically all of the phenomena of Europe in the first year of the war have been duplicated.
The most striking effect up to the present has been a morbid sensitiveness at any exhibition of diversity of opinion. One of the accompaniments of abnormal emotional states is likely to be an extraordinary sense of mental lucidity. The more irrational the condition, the greater the attendant sense of self-possessed rationality. So it is with us at present. Our reactions to dissent and criticism are mainly reactions of irritation, due to the hypersensitiveness of nerves on edge. But we justify our attacks and suppressions on the rational ground that social cohesion is a necessity, and that we are simply taking measures to secure union. That this rationalization is a piece of self-inflicted camouflage appears as soon as we call to mind the lessons of experience regarding the inefficiency of all prior attempts to dragoon thought and feeling.
from Hacker News https://ift.tt/0eDZbvA
Functional programming patterns in Smalltalk
Introduction
What is functional programming?, you may ask:
In computer science, functional programming is a programming paradigm where programs are constructed by applying and composing functions
Wikipedia’s definition of functional programming is OK, although purists would argue that functional programming includes pure functions that don’t modify state, and likely offer immutable data structures (as popularized by Clojure). However, Wikipedia’s definition is mostly good enough. In the past couple of decades the idea of lightweight functions, applied by library algorithms to provide a composable - and hopefully more declarative way of coding - has gained traction.
While it had been around before that, I was first introduced to functional programming concepts through C++‘s functional objects: create a small class that implements the () operator, maybe hold some data applied at call time, it gets called by some library algorithm at the appropriate time.
For more information on this pattern in C++, see “The Function Object Pattern”, from in C++ Report, Vol 9 #9, pages 32–42, October 1997.
Functional objects are great, and still a trick I sometimes use today: objects marry behavior with data, and functional objects were no different. Sometimes you need to seed some extra data into your lightweight function execution! This can be data in addition to whatever data you’re getting passed via an “for every element in this list, call this method passing as a parameter the current value” algorithm function.
Over the last decade I’ve seen functional paradigms become more and more accepted, and easier and easier to use as a developer. What once took you a whole C++ class and boilerplate is now a couple characters of syntax, for example.
In modern languages, almost every standard library leans into the idea of anonymous user provided functions (called lambdas or closures) for standard iteration and algorithm methods.
What if we look at functional programming concepts not through a modern language, but through the eyes of a 50 year old one? Smalltalk, first created in 1972ish, then widely released as Smalltalk-80.
Let’s first start by examining Smalltalk a bit, then jump into common functional paradigms in languages, from most frequently seen (in mainstream multi-paradigm languages) to least. (Yes, I know about Scala).
Smalltalk: a vibe shift
Smalltalk is one of the very first object oriented languages. It’s also super neat because it doesn’t have any built-in control structures!
record scratch
“Ummm, does that mean it can’t do if statements?”
Gentle reader, here’s how you do an if statement in Smalltalk:
true ifTrue: [ 'I was true' ].Here we have true (an instance of the Smalltalk True class, a subclass of Boolean). We call the method ifTrue: on it, and pass it a small, composable function. As the instance is true, our function is executed.
The False class’s implementation simply does nothing, which is an elegant way to solve this bootstrap problem: by polymorphism, a sprinkling of inheritance, and a language where everything everything is an object.
Back to those small, composable, inline function things. Smalltalk calls these little functions “blocks” (I assume because the square brackets makes it look like your logic is inside a little rectangle), but other languages call them closures or lambdas. Theoretically there’s a difference, but practically everyone uses either one of these three names to mean the same kind of thing.
Functional iteration
Functional programming is most often used when iterating over a list: selecting items from a list, transforming items in a list into a different kind of object, etc.
Done simply in Smalltalk. First, set ourList to a three array element, and we iterate on it
ourList := { 1. 2. 3 }.
ourList collect: [:in | in + 1 ].This returns a list: 2, 3, 4.
Sometimes you want to take a list, grab only certain elements out of it, then operate on those. Ideally you want to do this in an efficient way: only operating on elements you’re going to use: if a data element matches the select it is immediately processed by the collect, vs waiting for the entire list to be filtered.
ourList select: [ :num | (num \\ 2) = 0 ] thenCollect: [:n | n + 2]Two points:
- Yes, the method’s actual name is
select:thenCollect: - Yes, the collect closure is only called for even numbers
\\means mod / return the remainder
Smalltalk offers an OK collection of these complex methods. But maybe I have a situation where I want to select the even numbers, add two to them, then ONLY keep the result if it’s > 8.
Method Chaining
In this view of functional programming - the composing of small functions and moving data through a chain of operations - it should be easy to chain function calls together. The Lisp people often call these threads, or thread macros, which is slightly confusing because of CPU threading or when in languages, like Smalltalk, that don’t have macros.
Back to our example, what if we wanted to perform an additional select at the end of our select:thenCollect workflow above? Let’s say select:thenCollect:andCollectSomeMore: ?
Using an excellent 10 line chaining solution by Attila Magyar we can get just that:
ourList chain
select: [ :num | (num \\ 2) = 0 ];
collect: [:n | n + 2];
collect: [:m | m + 2].This is a wonderful, lightweight example of what Smalltalk can do, the expressiveness in almost zero syntax. (In Smalltalk ; means “send this message to the same receiver”. Which in this case is doing some state management an proxying those messages to the result of the last expression)
There is in fact nothing magical about this, we could write a similar thing by hand:
((ourList select: [ :num | (num \\ 2) = 0 ]) collect: [:n | n + 2]) collect: [:m | m + 2]This doesn’t feel good: counting the (s was not fun, even in this trivial example.
It’s worth noting that, unlike the builtin select:theCollect: method, chain does not result in a lazy workflow. The entire collect is processed in a step, then the entire thing passed off to the next step.
Deep Selection / Traversal Systems
In complicated APIs or programs, sometimes that data we want is deep inside a structure full of stuff we don’t. Chris Penner calls how we access this data a traversal system, where as Sergio Antoy and Michael Hanus’ paper on new functional logic design patterns (site) would call it “deep selection” (then they present an implementation that can only be achieved by functional-logic languages, so they may disagree with my application of the term.)
Anyway, traversal systems allow a developer to get a single value(s) “over there, and deep inside”. The Haskell community created the idea of lenses on data structures, and this idea has been ported to other languages (I’ve played with the Racket implementation and a Javascript one too).
So what does Smalltalk give us in these regards?
For Dictionaries, not lists like ourList, Smalltalk offers some object traversal methods.
First, we construct our objects to work with
deepDatadictInner := Dictionary newFrom: { 1 -> 2. 'myKey' -> 4. 5 -> 6 }.
outerDataDict := Dictionary newFrom: { 'outer' -> deepDatadictInner. 'inner' -> 'hi'}.Smalltalk’s Dictionary objets have an at:at: method which let you select an element from the Dictionary, then call at on that. Much like the select:thenCollect: method, you could duplicate this with some parans, but that’s ugly
outerDataDict at: 'outer' at: 'myKey'.returns 6.
Thats one of the basic, builtin methods from Smalltalk. Of course, it has limits as theres only at:at:, so for deeper objects you may need our chain method, above.
When Deep Select gets you in a bind: or stealing concepts from Kotlin (scope methods)
The Kotlin standard library contains several functions whose sole purpose is to execute a block of code within the context of an object.
In Kotlin this is called scope methods
What does this really mean? If you’re in the middle of a functional workflow, but need to do something not exactly functional, you can execute a block of code, getting the message receiver passed in as a parameter. Then pass the result of that expression to the next item in the chain.
Smalltalk’s has the in: method that does just that. We’ll see it here, without chain:
((ourList collect: [:in | in + 1 ]) in: [:newList | newList compact. newList. ]) asArray.compact doesn’t return anything, so we use in: to call it, then return our object again to keep the workflow working. (In Smalltalk, the value returned from a block is the result of the last statement in the block.)
(We could also get fancy and phrase the block like newList compact; yourself, where yourself is a message that returns it’s receiver / instance.)
We could write this without a functional workflow, it would just take more lines:
|newList|
newList := ourList collect: [:in | in + 1 ].
newList compact.
newList asArray.One line is somewhat more elegant here.
Traversal systems in Smalltalk when doing work with JSON
In the modern world of APIs, developers will often be dealing with API responses in JSON, and in normal RESTful intefaces the desired information may be deeply buried in some structure (unlike GraphQL where the client controls the shape of the object returned).
Smalltalk has the NeoJSON library with one class for happy, fast and dirty hacking: NeoJSONObject.
NeoJSONObject lets you access keys in a JSN structure as if they were messages in Smalltalk.
json := NeoJSONObject readFromString: jsonStringVersionOfOuruterDataDict.
json outer myKey.I really like traversal systems that are easy to write for easy cases. And if there’s a more complicated structure, perhaps use NeoJSONObject as far as you can, then use more fine grained tools where you have to.
Pattern Matching
A more complex control statement in modern languages is the idea of a “pattern matching” control structure. Think of it as a very good switch statement or an if with multiple conditions or results.
Kotlin calls this a when expression and it look like so:
when (x) {
0, 1 -> print("x == 0 or x == 1")
name == "ryan" -> print("even unrelated things do work")
else -> print("otherwise")
}Only one of these expressions will evaluate to true, and once matched no other branches are matched.
Since Smalltalk doesn’t even have if statements as syntax, can we add pattern matching to Smalltalk?
You betcha. I have, in rwilcox/PatternMatcher!
x patternMatchWithRules: {
PMRule whenMatches: [ :o | (o = 0) or: (o = 1) ] execute: [ 'x == 0 or x == 1' ]..
PMRule whenMatches: [ name = 'ryan' ] execute: [ 'hi, Ryan ].
PMRule whenMatches: [ true ] execute: [ 'else' ].
}In those PMRule lines, if the whenMatches block returns true the execute block is run. Else the next rule is evaluated.
Conclusion
Modern multi-paradigm languages allow for great functional patterns inside them. From languages almost nobody thinks of as functional (C++, Kotlin), to languages that are functional but impure (Racket), to pure functional languages (Haskell). These concepts can be cherry-picked into very unexpected places: the 50 year old very OO paradigm heavy Smalltalk. Smalltalk, which talks to providing almost nothing by the way of control structures lets bootstrapping and elegance happen by developers.
from Hacker News https://ift.tt/xThwR8s
Hungary will not allow lethal weapons for Ukraine to transit its territory
Hungary's Foreign Minister Peter Szijjarto addresses the 76th Session of the United Nations General Assembly, at the U.N. headquarters in New York, U.S., September 23, 2021. Mary Altaffer/Pool via REUTERS
Register now for FREE unlimited access to Reuters.com
PRISTINA, Feb 28 (Reuters) - Hungary will not send troops or weapons to Ukraine and will not allow lethal weapons to transit its territory in order to keep the country safe, Foreign Minister Peter Szijjarto said on Monday during a visit to Kosovo.
"The reason for making this decision is that such deliveries might become targets of hostile military action and ... we have to ensure the security of Hungary ... that we are not getting involved in that war," Szijjarto said after meeting Kosovo Foreign Minister Donika Gervalla.
Register now for FREE unlimited access to Reuters.com
Reporting by Fatos Bytyci; Editing by Daria Sito-Sucic and Kirsten Donovan
Our Standards: The Thomson Reuters Trust Principles.
from Hacker News https://ift.tt/vlr3oC4
Subscribe to:
Posts (Atom)