Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
I'm the first time to ask a question，I'm learning RxSwift, how to use bind to and driver, what's the difference between of driver and bind to.Anyone else learning RxSwift now.If you are learning RxSwift or Swift or OC,i hope we can be friends and learn from each other.
#iwillnot response is fine but I will try to improve it with an example:
Imagine you have this code:
let intObservable = sequenceOf(1, 2, 3, 4, 5, 6)
.observeOn(MainScheduler.sharedInstance)
.catchErrorJustReturn(1)
.map { $0 + 1 }
.filter { $0 < 5 }
.shareReplay(1)
As #iwillnot wrote:
Driver
You can read more in detail what the Driver is all about from the documentation. In summary, it simply allows you to rely on these properties:
- Can't error out
- Observe on main scheduler
- Sharing side effects
if you use Driver, you won't have to specify observeOn, shareReplay nor catchErrorJustReturn.
In summary, the code above is similar to this one using Driver:
let intDriver = sequenceOf(1, 2, 3, 4, 5, 6)
.asDriver(onErrorJustReturn: 1)
.map { $0 + 1 }
.filter { $0 < 5 }
More details
I suggest that you read the documentation for RxSwift Traits such as Driver.
Why use Traits?
Swift has a powerful type system that can be used to improve the correctness and stability of applications and make using Rx a more intuitive and straightforward experience.
By using units that follow constraints, we can rely on the compiler to show us errors if we're trying to do something we're not supposed to do (e.g. perform UI code on a Driver's drive method).
It is the same concept as to why we use data structures like Stacks and Queues depending on what is appropriate for the context or problem.
Driver
You can read more in detail what the Driver is all about from the documentation. In summary, it simply allows you to rely on these properties:
Can't error out
Observe on main scheduler
Sharing side effects
which is common when dealing with your user interface.
Why it's named Driver
Its intended use case was to model sequences that drive your application.
Community
Come join the RxSwift community in Slack if you are interested to meet like-minded and new and old RxSwift-ers. :)
Quotations are lifted from the documentation of RxSwift.
Related
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 2 years ago.
Improve this question
I am trying to compile Orange as part of OTAWA
However I get the below Error in file wcee.ml
Error: Unbound value IMap.print_ordered
The reason for the error is the below snippet.
let glb = common
(** Least upper bound. *)
let lub = IMap.combine max
(** Pretty printer. *)
let print = IMap.print CostItem.print Format.pp_print_int
(** Full printing. *)
let print_complete = IMap.print_ordered ~first:"" ~firstbind:">> " ~last:"" ~sep:"#\n" CostItem.print CostItem.known Format.pp_print_int
end
What is the reason for that ?
TL,DR: at first sight, it might be possible that the project currently just FTBFS (fails to build from source)? Anyway, I didn't attempt to compile it myself, but you may want to get in touch with the TRACES research team that maintains OTAWA to ask? (e.g., emailing Pr. CASSÉ…)
Further details:
the latest version of the source code seems to be online at this URL: wcee.ml,
which depends on tMap.ml,
the function you mention is defined via module IMap = TMap.Make(CostItem), which depends on the Make functor in the tMap compilation unit, which indeed does not seem to provide the print_ordered function,
hence the Unbound value error (which just means "this function is undefined!")
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 2 years ago.
Improve this question
I see react-d3. The last I used it for charts (prior to React), it was great until the layout of legends, margins, labels on the axes need adjusting. Using c3 and other libs on top of d3, made things easier.
Now I need to draw graphs - random node/link/group diagrams. I see Force layouts - but not simple graphs in react-d3. I looked at Cytoscape - it does not have an official React build, which seems to be in works (there is a wrapper I found on stack-overflow, but i am hesitant to use it until an the cyto team releases it.
The question therefore is:
- If I use react-d3, where can i find some samples (not charts and not 'Force' layouts)
- if using react-d3 directly is a bit too low-level, is a good library atop d3, now available for React? (I am willing to sacrifice the ultra-flexibility of d3, for ease of a simple library).
Any help and pointers is most welcome.
Thank you.
Tl;dr: Avoid react-* wrapper packages (for external libs) when you can. They'll tend to limit you later for all but basic usecases.
There's not really any reason to wait on a React adaptor for Cytoscape. The adaptor is being built for some guys who want to create really simple (mostly) visualisation-only React.Components -- like a simple page that goes along with a scientific publication.
In general, those react-* packages for external libs tend to fall into one of two categories, (1) simple libs or (2) complex libs. For (1), a react-* package could be OK if the lib it's wrapping has a small featureset to cover. For (2), these wrapper packages tend to cover only a small portion of the API. For both (1) and (2), you depend on the wrapper being up to date -- or being locked out of features.
As your app gets more and more developed, would you want to risk having to do a rewrite because your app is highly coupled to a react-* wrapper package that your app outgrew?
By and large, there's not that much benefit of using react-* wrapper packages. Especially for more complex cases like yours, you just limit what features you can use and how you can use them.
Whatever graph lib you choose -- be it Cytoscape or otherwise -- I recommend just writing your own React.Component tailored to what your app needs.
Personally, the only react-* packages I would use are ones that add features directly to React, like animations, routing, etc.
The resources above are 4 years old so thought to update. I would use react-digraph or react-flow - Both seems to be well supported.
you can have a look at the below library,
https://github.com/lavrton/react-konva
https://github.com/Flipboard/react-canvas
https://github.com/reactjs/react-art
https://github.com/alex3165/react-leaflet-draw
https://github.com/PaulLeCam/react-leaflet
Look at react-sigma, which is quite powerful and fast network graph rendering engine. It supports WebGL and Canvas, allows customizing node and edge shapes, have plugins for running animations like ForceAtlas2, Filter. Also it can be extended with custom components.
Simple use case
let graph = {
nodes:[{id:"n1", label:"Alice"}, {id:"n2", label:"Rabbit"}],
edges:[{id:"e1",source:"n1",target:"n2",label:"SEES"}]}
<Sigma graph={graph}
onOverNode={e => console.log("Mouse over node: " + e.data.node.label)}>
<RandomizeNodePositions />
</Sigma>
Loading from external file and running ForceAtlas2:
<Sigma style={{width:"200px", height:"200px"}}>
<LoadJSON path="/public/data.json">
<ForceAtlas2 worker barnesHutOptimize barnesHutTheta={0.6} linLogMode>
</LoadJSON>
</Sigma>
Extending with your own component:
class MyCustomSigma extends React.Component {
constructor(props) {
super(props)
props.sigma.graph.nodes().forEach(n => { n.label = "ID:" + n.id });
};
render = () => null;
}
...
return <Sigma>
<MyCustomSigma>
</Sigma>
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I have a if (a > b) { .. in my code, which I would like to explain why is there to someone looking at the code.
The reason for it being there is quite complicated and cannot be explained well without the use of images.
The question is, how to best document this to a programmer looking at the code? Is there a generally accepted way?
Should I create a comment in the code saying "See explanation XX", and then create a document somewhere containing XX?
Much of this will depend on what you are coding and the size of your project, but generally I would say that you should comment this particular conditional with an explanation only for what if (a > b) { .. is checking for, and why.
When you get to the content inside the if condition, explain that. Broader explanations as to the purpose of the function itself and its objectives should generally be in the declaration, although you can also add descriptions to the definition (I prefer to avoid this generally, although I sometimes describe the method in further detail on top of the definition, where it would simply clutter the declaration of the class).
For example,
class A
{
// this method performs operations on x or y as appropriate, given the input conditions of
// a and b. Its purpose is ... and in order to achieve this it does ...
void Method(int a, int b);
};
// elsewhere in a .cpp file
// Note that this method uses method abc rather than method cde in order to achieve
// such and such more efficiently (description here is more technical than in the
// declaration, and might focus on more specific issues while still remaining
// applicable to the function as a whole, and should therefore not be in the body)
void A::Method(int a, int b)
{
// check to see whether or not a > b in order to decide whether to operate on x or on y
if (a > b)
{
// a is greater than b, and therefore we need to operate on x because...
}
else
{
// a is not greater than b, therefore we need to operate on y because...
}
}
I find that by structuring my comments to address the reason why specific sections of code are the way they are, the reader is able to "follow the story" that the code is telling as she reads through it.
If it is absolutely impossible to describe what the if section is doing without a broader explanation, then by all means add a paragraph or two. There is nothing wrong with long comments as long as they are well placed and address the specific purpose of the following lines of code. You shouldn't need to add for more information, see function header because that should already be implied.
You can add broader descriptions to the enclosing function, method, or scope, but comments should always address the piece of code they are referring to as succinctly as possible. After all, if the reader wanted to know what the whole function was doing, she'd look at the declaration. The reason she's looking at the definition of the function is because she wants to know what the components of the function are doing, and so the comments should address just that.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I'm trying to refactor some code that reads a csv file. The first character in every line of the file indicates the type of record: H = Header, I = Information, and D = Data. Each record type has a fixed and different number of fields. My program uses FasterCSV to read a line from the file and then uses a case statement to determine how to process the line.
record_type = new_record[:record_type]
case record_type
when "H"
factory_build_H_record(new_record)
when "I"
factory_build_I_record(new_record)
when "D"
factory_build_e_record(new_record)
end
For refactoring, I'm trying to follow Sandi Metz' blog post on the use of case statements in OO programming and eliminate case statements. My inclination is that I need to create some classes that represent the three record types and then define some methods like process_record. I'm not sure how I should go about to create the classes. Any help would be appreciated.
The blog post you linked is specifically about using case statements to tell what kind of object something is. That is often a symptom of bad design, and that is the point she is making.
The way you are using a case statement is much more acceptable. In fact, no matter how you restructure this, you are going to be doing some kind of test (case, or if, or otherwise) against that column in order to determine the correct behavior for the row.
If your code later on has to try to tell those objects apart by their class (using a case statement or if), then you are violating the spirit of the blog article.
The solution, is to create objects that have the same interface (have the same methods, used in the same way. The behavior of those methods is different internally in each class to do the right thing for that object.
Hope this helps clear up the concept for you :)
Case statements are not bad for small and fairly static conditional cases like the one you have.
If (theoretically) you anticipated having more record types in the future (besides H, I, and D), then the problem with the case statement is that it might cause you to start violating the Open-Closed Principle.
In this case, you might create a set of RecordType classes that is something along these lines:
class HeaderRecordType
def is_mine(record)
...
end
def build(record)
...
end
end
class DataRecordType
...
end
class SomeNewRecordType
...
end
Then, instead of the case, you would just iterate over a list of all the RecordType's (or use a Chain of Responsibility) and ask each one is_mine(record). As soon as one of them says yes, then you stop looking and call build.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I develop a software with Oracle form builder for my final thesis. I want to prepare some of software development document for my final thesis report.
as you know oracle forms blow ver 8.0 is procedural base... I use oracle form 6...
I need to prepare Software Requirement Specification (SRS) and Software design document (SDD) for my report.
the problem is, As we know oracle form is procedural base and it is not Object oriented base I used SSADM methodology for show how my forms are related(draw DFD,CFD,PSPEC)(use cases and flow up events[in uml]) together and their working in generally... right now for SDD I dont know how I should show my low level ,high level desing, and packages...
Which methodology you offer to me? right now I try to show my my low level ,high level desing by TOOD, but several days ago I find out TOOD is also for Obejct Oriented program,please help me...
One more question we can not use UML for funtional base program?Please with a strong reference plz...
I so worry that my examiner doesn't accept my work...
It is so hard drawing GUI by SSADM :(( plz help me...
I hope you expert people that gathering here can help me...
In my SRS template for UML project before I put : Usecase diagram,and sequence diagram.
and for SDD before in a OO prject I put : Class diagram, package ,component diagram and describe all my Class and than all of function of class (I dont know now how show them for my procedural base project :(( )
A history lesson.
The closest thing to an official methodology for building Oracle applications is the late Oracle*CASE Method. I doubt whether anybody has used it in a decade. Although it did exist as a process, really it was a guide to using Oracle CASE (subsequently Oracle Designer), which itself is a mothballed product.
CASE and Designer used variations on the SSADM product set. So in the analysis round we defined modules with DFDs. When it came to the design phase we decorated those definitions with the Design Editing tool with which we could specify the GUI elements. But I don't think that diagrammer had ties to any recognised methodology.
I would have included a link to some information about Oracle*CASE method, but it is so old it is pre-Internet (if you can imagine such a thing).
If the eTOOD approach allows you to describe Forms by all means use it. When it comes to GUI I don't think there's much difference between OO and procedural approaches. Although Jackson Structured Programming (or SDM) remains the best way of representing the flow through all the Forms triggers.
My key advice to you is talk to your examiner. Find out what they are expecting. Saying some random bloke at StackOverflow told you to use a certain methodology is unlikely to improve your grade.