felix91gr / awesome-system-swift Goto Github PK

GeoFeatures2 has not been released yet. Once it has, we want to add it to the index.

Excerpt from #19:

GeoFeatures*: GeoFeatures1 is running in production on many applications but as GeoFeatues2 has not been released yet. I do plan on releasing a beta shortly (within a few weeks or so) that contains the core, wkt, GeoJSN, and visualization. We'll follow on with the algorithms such as union, intersection, etc.

#### Geometry libraries
> _Tags: geometry, shape, map, point, linestring, polygon, multipoint, multilinestring, multipolygon, geojson, wkt, intersection, union, within, contains_
* [GeoFeatures](https://github.com/tonystone/geofeatures2): A lightweight, high performance geometry library in Swift. Runs on ios, osx, and linux.

Tangent of #17

Having the <details> HTML tag available allows us to be more descriptive of why we require tests in libraries before listing them. The idea here is to come up with a better explanation, now that we don't have the limitation of space.

This is the current explanation:

Why are tests required for libraries? Libraries, unlike apps, can't be run to check that they work as intended. Therefore, tests are essential to maintain them. Tests are also very convenient to check that they work on all supported platforms.

We should provide a checklist for new projects and the criteria they should fulfill (e.g. At least working on Linux compatability).

Additionally PR and issue templates may be interesting.

I was reading the index and this jumped out at me. "Logging" seems like a very specific category, and maybe it could be moved into a more general one and maybe be reworded as well.

I'd say that logging is a kind of workflow, and therefore it would go under the Workflow-enabler Frameworks section.

But apart from that, is "Logging" itself a workflow, or is it part of a more general thing? Like how asyncronous and reactive programming are part of the same family. I was thinking that maybe that category would be:

Logging and Tracing

or something like that.

Thoughts? @tonystone @vknabel
I've never used logging extensively, so I'm out of my knowledge here. Where does logging belong?

Also, related to this. @tonystone: does TraceLog do tracing? In the sense that uftrace does "tracing"? Or is it in this context, an alternative word for logging?

StickyLocking has not been released yet. Once it has, we want to add it to the index.

Excerpt from #19:

StickyLocking: Complete, but not yet released. Plan to release it in beta shortly. I want to release it concurrently with StickyEncoding (https://github.com/stickytools/sticky-encoding) which still requires some documentation and readme updates.

#### Locking / Concurrency libraries
> _Tags: lock, locking, lock-manager, mutex, conditions, concurrency_
* [StickyLocking](https://github.com/stickytools/sticky-locking): A general purpose embedded hierarchical lock manager used to build highly concurrent applications of all types. Runs on ios, osx, and linux.

Here I'm gonna put the libraries that seem to be:

• Well supported
• Well tested
• Cross-platform
• Production-ready: developed enough to be used by third parties. For example, CompilerKit fits all of the above but it's not yet finished, and thus can't be put on the same list as everything else.

Workspace has no stable release compatible with Swift 4.1 yet; the last stable release works with Swift 4.0.3.

But Workspace is still usable with Swift 4.1 when built from source on its swift‐4.1 branch. (It is unrelated parts of dependencies that delay their release and force Workspace to link against their branches instead of stable versions.) Just use it only from the command line for now, because the scripts mentioned in the read‐me will try to retrieve the stable version and fail to compile under Swift 4.1.

There are many changes and improvements already on the to‐do list, but I would be interested to know what you think.

Because it allows us to show:

1. State of development
2. Systems supported
3. A good description: use cases, for example

All of this, without cluttering everything

So, it's something to think about. We'll try and see.

This would help us run tests on projects that don't have the LinuxMain.swift file. How to do it, is up to us. We know that:

• SPM on Darwin can generate it.
• Sourcery could probably do it as well.

And here are some ideas on how to do it:

• Make a python crawler that generates the LinuxMain file, with extensions and all (I've already tried this partially and it works; it can be done).
• Sourcery can do it, but it's still not working on Linux.
• Synthesize it on Darwin (with SPM) and copy it to Linux through Travis (I don't know if this is possible, the VMs are probably sandboxed).

Other use cases:

• This could help Linux users to port a project they like to Linux. It could even be integrated into something like swiftenv, s.t. you can generate the LinuxMain.swift file automatically.

I think they have a place. Maybe in this document, or maybe in a dedicated repo about "tools to set-up Swift".

It feels weird adding swiftenv directly here. Not because it's bad (because it's actually magic and rainbows), not at all, but rather because it's not a Swift project per se, but is like a set-up-Swift project. I don't know.

Maybe they should be included in the index, and be mentioned at the top, s.t. a newcomer can know right away where they can go.

@vknabel had a really great idea about how to add CI such that we could test the projects both periodically and before merging a PR, to see that they worked on both Darwin and Linux.

These are the benefits:

• This helps us maintain our goal of listing cross-platform libraries.
• This helps a contributor (and us!) know what might be missing in a newly added project, instantly and with extensive feedback.

And this is (more or less) the idea as I can recall it:

• Parse the document for links, and check if the repo has the structure of a Swift SPM project. If not, whatevs.
• If yes, then download it and run swift test. Collect the results (passed/total and console output) into a list.
• Display the results in the PR.

This would be enhanced by tools such as that described by #31