Is there an updated list of Swift global functions? That is, functions that can be accessed from anywhere without the scope of a specific type, like max(),min(),dump(), zip(), sequence(), etc.
On the Apple docs the nearest link I found out is link, but it only refers min and max.
When building project documentation in docC by default all the global functions for a particular module are grouped under Functions section similar to Protocols section for protocols etc. Apple has customized this behavior so that global functions are grouped in different sections depending on their usage topic. Right now there is no way to list all of the global functions, you have to find them one by one manually. However, there is some work going on to implement fuzzy search on docC documentations to search using certain type of symbols etc.
Related
I see many instances of # sign like #package_name or #somthing in dart. Although I know the usage of some examples like #override, I can't understand why some packages(eg: #freezed) or dart syntax(eg: #immutable,#lazySingleton) use this operator and what its functionality is.
it's metadata read here about it: dart language-tour
As Kherel mentioned, the # symbol is for metadata. It helps developers keep track of certain functions for future purposes.
If you want, you can then use that metadata for programmatic purposes using the 'dart:mirrors' library.
For example, flutter uses #override to ensure that child classes are allowed their specific behavior, separate from the parents.
The most common usage is to classify functions and classes in some way for easy access. IDEs may also keep track of certain metadata to warn you about the way functions operate (via #TODO or #deprecated, for instance).
Just wondering whether there is any support for comments considered as documentation for enums and classes members (methods and fields / properties) in PowerShell?
If you're referring to the equivalent of Comment-Based Help, I've seen no indication of any. However, if you're writing classes or enums, you are also presumably writing scripts or script cmdlets/advanced functions that rely on them; it wouldn't be unreasonable to document the classes or enums in the scripts/etc. that use them.
Trevor Sullivan provides a link below to building your own about_Topic help data files; this represents another possibility, and one that may well be more appropriate, depending on how you're using your classes/enums.
I am not able to understand what is the difference between these two keywords in swift3?
If anyone has a link to a good article about this, please share.
There is no difference conceptually; moduleprivate was just a possible alternate name for the same access level that didn't get accepted during discussions about access control modifier naming.
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160328/013854.html
The internal modifier is the only one of the two that actually exists in the Swift language, but the two names represent the same behavior.
I'm having a hard time deciphering Scala API documentation.
For example, I've defined a timestamp for use in a database.
def postedDate = column[Timestamp]("posted_date", O NotNull, O Default new Timestamp(Calendar.getInstance.getTimeInMillis), O DBType("timestamp"))
If I hadn't read several examples, of which none were in the API doc, how could I construct this statement? From the Column documentation how could I know the parameters?
I guessed it had something to do with TimestampTypeMapperDelegate but it is still not crystal clear how to use it.
The first thing to note from the scaladoc for Column is that it is abstract, so you probably want to deal directly with one if its subclasses. For example, NamedColumn.
Other things to note are that it has a type parameter and the constructor takes an implicit argument of a TypeMapper of the same parameter type. The docs for TypeMapper provide an example of how to create a custom one, but if you look at the subclasses, there are plenty of provided ones (such as timestamp). The fact that the argument is declared as implicit suggests that there could be one in scope, and if so, it will automatically be used as the parameter without explicitly stating that. If there isn't an implicit in scope that satisfies the requirement, you'll have to provide it.
The next think to note is that a TypeMapper is a trait that extends a function with an argument of a BasicProfile and a TypeMapperDelegate result. Basically what's going on here is the definition of a type mapper is separated from the implementation. This is done to support multiple flavors of database. If look at the subclasses of BasicProfile, it will become apparent that ScalaQuery supports quite a few, and as we know, their implementations are sometimes quite different.
If you chase the docs for a while, you end up at the BasicTypeMapperDelegates trait that has a bunch of vals in it with delegates for each of the basic types (including timestamps).
BasicTable defines a method called column (which you've found), and the intent of the column method is to shield you from having to know anything about TypeMappers and Delegates as long as you are using standard types.
So, I guess to answer your question about whether there is enough information in the API docs, I'd personally say yes, but the docs could be enhanced with better descriptions of classes, objects, traits and methods.
All that said, I've always found that leveraging examples, API docs, and even the source code of the project provides a robust way of getting up to speed on most open source projects. To be quite blunt, many of these projects (including ScalaQuery) have saved me countless hours of work, but probably cost the author(s) countless hours of personal time to create and make available. These are not necessarily commercial products, and we as consumers shouldn't hold them to the same standards that we hold for-fee products. If you find docs inadequate, contribute!
I'm struggling with the size of output files for large Modelica models. Off course, I can protect some objects in order to remove them completely from the result file. However, that gives rise to two problems:
it's not possible to redeclare protected objects
if i want to test my model in detail (eg for a short time period), i need to declare those objects publicly again in order to see their variables
I wonder if there's a trick to set the 'verbosity' of a Modelica model. Maybe what I would like is a third keyword next to public, protected, eg. transparent. Then, when setting up a simulation, I want be able to set the verbosity level to 1, or 2 with the following effect:
1--> consider all transparentelements as protected
2--> consider all transparentelements as public
This effect would propagate to all models and submodels.
I don't think this already exists. But is there an easy workaround?
Thanks,
Roel
As Michael Tiller wrote above, this is not handled the same way in all Modelica tools and there is no definite answer. To give an OpenModelica-specific answer, it's possible to use simulate(ModelName,outputFilter="regex"), to store only the variables that fully match the given regex (default is .*, matching any variable).
Roel,
I know several people wrestling with this issue. At the moment, all of this depends on the tool being used. I don't know how other tools handle filtering of results, but in Dymola you control it (as you point out) by giving the signals special qualifiers (e.g. protected).
One thing I've done in the past is to extend from a model and then add a bunch of output signals for things I'm interested in. Then you can select "Outputs" in Dymola to make sure those get in the results file. This is far from perfect because a) listing everything you want can get tedious and b) referencing protected variables is not strictly allowed (although Dymola lets you get away with it but issues a warning).
At Dassault, we are actively discussing this idea and hope to provide some better functionality along these lines. It isn't clear whether such functionality will be strictly tool specific or whether it will involve the language somehow. But if it is language related, we will (of course) work with the design group to formulate a specification that other tool vendors can support as well.
In SystemModeler, you go to the Settings tab in the Experiment Browswer in Simulation Center. Click on Output on the bottom and select which variables to store.
(The options are state variables, derivatives, algebraic variables, parameters, protected variables and if you mark the Store simulation log-option, you'll get some interesting statistics on events over time and function evaluations, opening another possibility to track down parts of the simulation and model that creates more evaluations)
I am not sure if this helps you, but in Dymola you can go to Simulation->Setup->Output and mark a checkbox saying "Store Protected variables". That way it is possible to declare most variables as protected: during normal simulation they are not stored, but when debugging your model, you just mark that checkbox and they are stored.
Of course that is not the same as your suggested keyword transparent, but maybe it helps a little...
A bit late, but in Dymola 2013 FD01 and later you can select which variables to store based on names (and model names) using the annotation __Dymola_selections, and even filter on user-defined tags - so you could create a tag name "transparent" in the model. See "Matching and variable selections" in the manual.