OpenLLM-France/wikimedia huggingface dataset:
# Lombard/Moods and tenses/Use of tenses

| Description of use | Tense in English | Tense in Lombard |
| Actions done often (with adverbs of frequency) | Present simple | Present |
| Facts and conditions that do not change | Present simple | Present |
| Future planned | Continuous present | Future (in colloquial form also Present simple) |
| Actions that repeat continuously (with adverbs of frequency) | Continuous present | Continuous present |
| Past actions not yet finished | Present perfect | Past |
| Past actions with effects still present | Present perfect | Past |
| Action just finished | Present perfect | Past |
| Actions carried out in the past for a continuous time and not yet completed | Present perfect continuos | Past |
| Actions carried out in the past for a continuous time and not yet completed with emphasis on the commitment and duration to carry out the action | Present perfect continuos | Past or Past continuos |
| Action just finished with effects still present | Present perfect continuos | Past |
| Actions past forever | Past simple | Past |
| Actions passed forever, with emphasis on the commitment to carry them out and their duration | Past simple | Past or Past continuous |
| Description of a context in which another action takes place in the past tense | Past continuos | Imperfect or Past continuous (to highlight the duration of the action) |
| Action that started in the past before another past action | Past perfect | Past perfect |
| Actions carried out in the past for a continuous time and not yet concluded in the past moment we are talking about | Past perfect continuous | Past perfect |
| Actions carried out in the past for a continuous time and not yet completed in the past moment we are talking about with emphasis on the commitment and duration to carry out the action | Past perfect continuous | Past perfect or Past perfect continuos |
| Actions just finished in the past moment being talked about with effects still present at that moment | Past perfect continuous | Past perfect |
| Decision for the future | Future simple | Future simple (in colloquial form also Present simple) |
| Prediction for the future | Future simple | Future simple (in colloquial form also Present simple) |
| Intention or plan for the future or premeditated decision | Future “to be going to” | Future simple |
| Future action that develops over time in the future moment being spoken about | Future continuous | Future simple |
| Future action that will develop over time, with emphasis on the commitment to carry it out and its duration | Future continuous | Future continuous |
| Action that will be finished at the future moment of speaking | Future continuous | Future continuous |
* 1 2 3 4 5 6 7 8 It is constructed similarly to the English present perfect
* 1 2 3 It is constructed similarly to the English present perfect continuous
* ↑ It is constructed similarly to the English past perfect continuous
# Lombard/Morphology
## Parts of speech

* Articles
* Nouns
* Adjectives
** Adjective degrees
* Pronouns
** Subject personal pronouns
** Object and term personal pronouns
** Pronominal and adverbial particles
** Demonstrative pronouns
** Possessive pronouns
** Indefinite pronouns
* Verbs
** Moods and tenses
*** Infinitive
*** Gerund and gerundial complement
*** Participle
*** Present Indicative
*** Past Indicative (Perfect Indicative)
*** Imperfect Indicative
*** Past perfect Indicative
*** Simple Future Indicative
*** Compound Future Indicative
*** Present Subjunctive
*** Past Subjunctive (Perfect Subjunctive)
*** Imperfect Subjunctive
*** Past Perfect Subjunctive
*** Present Conditional
*** Past Conditional
*** Present Imperative
*** Future Imperative
*** Continuous construction
** Irregular verbs
** Auxiliary verbs
** Modal verbs
** Phrasal verbs
* Prepositions and prepositional locutions
* Adverbs and adverbial locutions
** Pronominal and adverbial particles
** Negation
** Other constructions replacing the adverbs "easily" and "hardly"
* Conjunctions and conjunctive locutions
# Lombard/Object and term personal pronouns

In Lombard the personal object pronouns are equal to subject personal pronouns, even those that act as a complement of term or advantage are equal to subject pronouns but preceded by the preposition a. The personal pronouns for direct object and complement of term can also be expressed through pronominal particles (See ►►► Pronominal particles)
# Lombard/Past Indicative

* The reference orthography for this page of Lombard course is New Lombard orthography
In Lombard, the distant past became extinct during the 19th century. Nowadays it is replaced by the past built similarly to the English present perfect (present indicative of the auxiliary verb + past participle). The auxiliary verb is vesser (conjugation) for reflexive and most of intransitive verbs, havè (conjugation) for transitive verbs.
# Lombard/Lexicon

* Flora
* Animals
* Food and Drink
* Transport
* Factories, Shops and Trade
** Slang
* Place names
* Personal names
# Lombard/Participle

* The reference orthography for this page of Lombard course is New Lombard orthography
* In Lombard there is no present participle (however it was introduced as Italianism in some dialects) but just its periphrases.
** paying = che 'l paga. (“that pays” that it the periphrasis that plays the role of the present participle that would be instead “pagant”)
* The past participle, on the other hand, exists and is widely used (especially to form compound tenses, but also as an adjective).

## Formation of the regular past participle

As for spelling, the formation of the past participle in New Lombard Orthography has already been described in the module about the orthography. However, the pronunciation of the ending differs from one dialect to another.
To know the pronunciation IPA in the various dialects please refer to the appendices of the wiktionary in Lombardy:

### Western lombard

→First conjugation →Second conjugation →Third conjugation →Forth conjugation

### Eastern Lombrd

→First conjugation →Third conjugation →Forth conjugation

### Alpine Lombard
## Irregular past participles

►► vedi ►► Lombard/Irregular verbs
# Oracle and DB2, Comparison and Compatibility/Database Scaling/Replication

One of the easiest ways of spreading data processing loads and providing a degree of fault tolerance is to simply copy the data in the database somewhere else and start another instance running against this copy. This strategy is called replication. It’s one of the simplest and most often implemented strategies. Both IBM and Oracle have a number of replication solutions. We are defining replication here as Master-Slave replication – where there is only one place that the data is updated (the master), and these changes are propagated to other instances (slaves). Master-Master replication (where any instance is capable of updating data) is covered later on under the topic of Shared Architectures, since the synchronization of multiple updates is critical in these systems, it is the processing functionality that is replicated, the data typically does not get copied elsewhere. In Master-Slave replication systems the replication can be either synchronous or asynchronous. The difference is simply the timing of propagation of changes. If the changes are made to the Master and Slave at the same time, it is said to be synchronous. If changes are queued up and written later, it is asynchronous.
There are a number of ways of propagating changes to the slave systems. In Trigger-Based replication, triggers on columns in the Master system will write changes to the Slave system. Trigger based replication can be synchronous or asynchronous.
Trigger Based Replication
Log Based Replication
In Log Based replication, the transaction log files are copied to another instance and replayed there. The log files are intended to reproduce a working version of the database in the event of a failure, so they represent an ideal mechanism for replicating data. In this instance the Log Files are streamed to a database instance that continuously recovers this data. Log based replication is only asynchronous.
Replication Uses
Data Replication is an easy way of providing data and system backups. Since the data being replicated will function as a database, replication is effectively a data backup. In Master-Slave systems, the Slave databases are read only. If the data is being replicated to a running database instance, it can provide a system backup in the event that the master becomes unavailable. This is called warm standby, and the slave system can be turned into a master by making it read/write. This is a simplistic description of warm standby, if your master becomes unavailable, there are probably other things that you will need to do to promote the slave to master besides just making it read/write.
Replicated databases are a good way of offloading database processing as well. The read only slaves can be used for reporting and DSS applications. In this way read only operations are offloaded to the slaves, freeing up processing cycles on the master.
# Oracle and DB2, Comparison and Compatibility/Introduction

Many of Oracle's most important De Facto PL/SQL standards have now been implemented by IBM. IBM is aiming to compete on performance, usability, high end features and (of course) price. This Wikibook compares and contrasts Oracle (v9i, 10g or 11g) with DB2 (v9.7 for Linux, UNIX, and Windows). Oracle and DB2 are both enterprise-class databases worthy of consideration for the most demanding tasks and this book aims to be factual and impartial in helping the user to compare and contrast them.
- How similar architecture is implemented in each DBMS - What Oracle compatibility is implemented in DB2
Generally, anyone who has knowledge of one of these databases will see how equivalent core functionality is implemented in the other. Specifically, you will see how DB2 implements Oracle compatibility and how Oracle data and applications written against this data work in DB2. It is important to note that while it is possible to replace an Oracle implementation, it is also possible to develop heterogeneous systems, the so-called ‘Sidecar Strategy’. Examples of this are master slave replication where an Oracle master is replicated to DB2 slaves. As an example, both databases work in shared memory and use data caching for speed, they also have the following similar functionality:
- SQL Syntax
- Built-In Functions and Packages
- Transaction Management
- Packages, Procedures and Triggers
- Indexes
- Data Caching
- Database Maintenance Tools
- Cursor handling
- Replication
- High Availability
- Bulk Loading
- Disaster Recovery
While there is similarity in these areas, the underlying implementation is different. This list is a standard requirement for most commercial DBMSs, but in addition Oracle has its own set of specific features. Anyone considering Oracle compatibility needs to know how features that they have taken advantage of in their existing implementation are handled in their target implementation.
Database migration is relatively straightforward, it happens every day, however the devil is in the details. When specific implementation differences are known, there are known solutions. Problems arise when differences are ‘discovered’ once a migration strategy has been embarked on. An understanding of Oracle compatibility is the first step. The practical implementation of a successful strategy is outside the scope of this document and is something that should involve the experienced.
# Oracle and DB2, Comparison and Compatibility/Architecture

* Overview
* Oracle
* DB2
* Summary
# Oracle and DB2, Comparison and Compatibility/Database Scaling
## Introduction

Because of their flexibility and degree of standardization, relational file systems have become the preeminent storage choice for businesses. The ability of relational databases to store huge amounts of data (literally, petabytes at the time of writing) and the desire of organizations to gather more and more information have advanced the requirement for relational databases beyond being simply huge repositories for information.
The first of these requirements is speed. There is a certain human expectation in system response time, and people expect modern systems to be faster. The explanation that individual response times might be slowing but that overall more concurrent users and orders of magnitude more data are being handled sounds more like an excuse than a reason. This opens an immediate opportunity for those organizations (Both database vendor organizations and database consumer organizations) that can service greater user and data populations faster.
Next comes availability. The Internet has facilitated round-the-clock business operations, so the file systems supporting this information need to be highly available (HA). High availability implies fault tolerance – the ability of data systems to quickly recover from system failures of any description, and to protect themselves against single points of failure hamstringing operations. This naturally leads to de-centralization, a geographical and logical separation of computing resources and data.
The requirement of “lots of data, quickly available to lots of people, all the time, everywhere” can be solved in several different ways, and can simply be described as spreading the requirement across the available resources – either spreading out the data, spreading out the processing, spreading out the hardware or combinations of all three. The strategies are relatively straightforward, and each is described in this section. Since the implementation of these strategies requires the coordination of several moving parts (data, memory, hardware and networking) they involve additional cost and a degree of planning in advance. This means that people do not tend to implement them just because it is technically possible, implementations tend to be based on “what is the simplest and most cost effective solution to my requirement”.
There are a number of ways of organizing data and processing power that is independent of database vendors. We are going to begin with a description of these:
Overview of Database Topologies:
So far our architectural descriptions of a database have looked like this:
This model has provided a framework for comparison of functionality, since in general databases need to do the same things, and they go about them in the same ways (i.e. moving data from disk to memory and back again, logging transactions, executing queries etc.)
* Replication
* Shared Architectures
* Oracle
* DB2
# Oracle Database

The Oracle Database (also referred as Oracle RDBMS or Oracle) consists of a relational database management system (RDBMS) produced and marketed by Oracle Corporation. Oracle had become a major presence in database computing.

## Table of Contents

* Introduction
* Database Interfaces
* Administering Users
* Tables
* SELECT Statement
* Restricting and Sorting Data
* Controlling
* Storage Structures
* Managing Data
* Views
* SQL
* PL/SQL
* XML Management
* Multimedia Databases
* Spatiotemporal Databases
* 10g Advanced SQL
* Regular Expression Support
* Net Services
* Shared Servers
* Performance Monitoring
* Proactive Maintenance
* Undo Management
* Monitoring and Resolving Lock Conflicts
* Backup and Recovery Concepts
* SQL Cheatsheet

## References

* "Oracle Database Podcasts".
* "OracleLearning: official videos".

## See also

* w:List of content management systems
# Optimizing Code for Speed/Conclusion

When I mentioned this article to some people on IRC (while it was still incomplete), someone said that "The first rule of optimization is 'Don't!'". I think such attitude is harmful. While I agree that "premature optimization is the root of all evil", sometimes one's code is just too slow and needs to be optimized. And if your code is what Joel Spolsky calls "Shrinkwrap" (i.e: code that is sold or otherwise distributed and made available for public consumption) then you can often not make assumptions on how fast it needs to be, and the faster it is - the better.
Speed and optimizing other resources are one important factor in the general, abstract quality of programs. If your program is slow, it is likely going to make your users frustrated and unhappy, which will be a failure in your mission as a software developer. So it is important that your program is fast enough, if not very much so.
My aim in this document was to explain the "why"'s, "what"'s and to a lesser extent "how"'s of optimization. I hope I was successful, and that people who read it will be more willing to optimize their software and more clueful in how to do so.

## Further Reading

Jon Bentley discussed various kinds of optimisations extensively in the book Programming Pearls 2nd Edition ISBN 0-201-65788-0. which is a very recommended read. He also recommends there his out-of-print book Writing Efficient Programs ISBN 0-13-970244-X for more discussion on the subject. There's also a lot of discussion on optimisation in the book The Algorithm Design Manual, 2nd Edition ISBN 978-1848000698.
The paper "Why Userspace Sucks" by Dave Jones details some bad practices in the GNU/Linux userland applications that hurt performance. Steve Souders gave an amusing talk titled "The Illusion of Speed". A blog post titled “Premature optimization is the root of all evil” is the root of evil also gives some insights.
Finally note that in 2018, I wrote a summary for an essay about "reflections how software quality has improved or worsened".

## Thanks

I'd like to thank Daan for expressing a lot of interest in this article, and for his constant encouragement and input. Limbic_Region has given me some useful input for this article by email. Several people have made some contributions to this article: Jguk, Dallas1278 and the IPs 84.27.42.81, 85.146.243.13, 203.196.46.108, 70.176.53.73, and 213.129.10.120 . I'd also like to thank all the originators of the sources that I quoted or referenced in the article.
# Optimizing Code for Speed/How to best optimize?
## Automated tests

The first thing you need to do before optimizing is make sure that your code has many automated tests with a good test coverage. Optimizing the code (or any other kind of modification) may break something, and the automated tests will likely and hopefully catch that.

## Refactoring

The next thing you need to do is to make sure your code is modular. Duplicate code and other properties that make a code non-modular can prevent a clear analysis of the code's bottlenecks by profiling it.

## Profiling

Both before and after changing code to "optimize" it, it is important to profile your code using a good software profiler. There are many profiler tools. Profiling will help show which code does not take a lot of time to run and therefore it would be best not to invest a lot of optimization effort in it. One should start by optimizing the most time-consuming tasks first.
It takes some expertise to know how to properly analyze the results given by the profiler, and seeing what needs to be optimized. For example, some IO-intensive routines may appear to consume a lot of time, while in fact that time cannot be effectively eliminated because the amount of IO is minimal (while still being relatively time consuming). I feel that discussing this aspect of profiling further is orthogonal to the mission of this article, so I'm not going to cover it here.

## Code review

Finally, it is a good idea that someone will review the code and give general remarks on speed bottlenecks found there. To quote Eric Raymond from "The Cathedral and the Bazaar" "Given enough eyeballs, all bugs become shallow".

## Other ways to optimize

Someone who commented on the first draft of this essay, said I was not giving enough focus about profiling and said that "profiling is the only good way to optimize.". While I agree that one should profile before optimizing, I strongly disagree that the only way to optimize is by profiling first.
For once, it's possible that one will perform accidental optimizations by trying to achieve a different aim. Sometimes I increased Freecell Solver's performance by changing the code in order to overcome running out of stack on Windows NT. Moreover, sometimes a programmer can realize that changing an aspect of the program in a certain way will increase the performance without profiling the code.
Finally, sometimes profiling the code (at least with the limited tools that one has) does not tell one much. On one of my projects after profiling, the most offending function takes about 15% of the time, with most of the other top candidates taking a few percents. So what should I profile there?
So while profiling is important, it is not the only good way to optimize and sometimes one needs to take different approaches.
# Optimizing Code for Speed/Optimization by Changing the Dependencies

Often the original choice of programming languages, or libraries can affect the execution speed, because they are not very optimized, too bloated, or otherwise too slow. Moving to a different programming language or library, including possibly replacing third-party code with your own, may have a positive effect on one's program's speed.
For example, if you're doing a lot of number-crunching code in dynamic, P-code languages such as Perl, Python or Ruby (at least without utilizing such APIs as PDL or SciPy) or otherwise your code involves many loops and conditionals, then you can expect it to run slower than if it was written in C or Assembly.
Similarly, I found that GLib's balanced binary trees performed more poorly than those of libavl and libredblack, and that its hash table performed more poorly than my own custom hash table (which was since then optimized further). As a result, eliminating a dependency on GLib's data structures may improve the performance of the program.
# Optimizing Code for Speed

This work is licensed under the:
* The Creative Commons' Attribution License version 2.5 - or at your option any higher version.
* The GNU Free Documentation License version 1.2 - or at your option any higher version.
Please keep it this way. If you don't like either or both licenses - feel free to fork it and have a different derived license. (While properly accepting the terms of either license as starting points).
Authors: User:Shlomif.

## Table of Chapters

* Introduction
* How to best optimize?
* Order of Complexity Optimizations
* Factor Optimizations
* Optimization by Changing the Dependencies
* Optimizing by Reducing Feature-Set
* Conclusion

## Other Resources

* Optimizing Code for Speed/Outline - relatively old